Providing alternative implementations to your bean

One of the greatest features of CDI is that you can provide two or more different implementations to the same bean. This is very useful if you wish to do one of the following:

• Handling client-specific business logic that is determined at runtime. For example, providing different payment mechanisms for a purchase transaction.
• Supporting different versions for different deployment scenarios. For example, providing an implementation that handles taxes in the USA, and another one for Europe.
• Easier management for test-driven development. For example, you can provide a primary implementation for production, and another mocked one for testing.

To do that, we should first rewrite our bean as an abstract element (abstract class or interface) and then we will be able to provide different implementations according to the basic OOP principles. Let's rewrite our bean to be an interface as follows:

public interface MyPojo { 
    String getMessage(); 
} 

Next, we will create an implementation class to our new interface:

@Dependent 
public class MyPojoImp implements MyPojo{ 
 
    @Override 
    public String getMessage() { 
        return "Hello CDI 2.0 from MyPojoImp"; 
    } 
} 

Now, without any modifications to the servlet class, we can test re-run our example; it should give the following output:

Hello from MyPojoImp !

What happened at runtime? The container has received your request to inject a MyPojo instance; since the container has detected your annotation over an interface, not a class stuffed with an actual implementation, it has started looking for a concrete class that implements this interface. After that, the container has detected the MyPojoImp class that satisfies this criterion. Therefore, it has instantiated and injected it for you.

Now, let's go on with the critical part of the story, which is providing one more different implementations. For that, of course, we will need to create a new class that implements the MyPojo interface. Let's create a class called AnotherPojoImp as follows:

@Dependent 
public class AnotherPojoImp implements MyPojo{ 
 
    @Override 
    public String getMessage() { 
        return "Hello CDI 2.0 from AnotherPojoImp"; 
    } 
} 

Seems simple, right? But if you checked our servlet code again, and if you were in the container shoes, how would you be able to determine which implementation should be injected at runtime? If you tried to run the previous example, you will end up with the following exception:

Ambiguous dependencies for type MyPojo with qualifiers @Default

We have an ambiguity here, and there should have some mean to specify which implementation version that should be used at runtime. In CDI, this is achieved by using qualifiers, which will be the topic of the next section.