Should I use @EJB or @Inject

Anatomy of @Inject

@Inject is a part of the CDI specification and works with a broad array of managed beans. It's not just limited to EJBs and accepts any bean conforming to the bean definition in the CDI context. It shines with its typesafe injection, object scope awareness, and advanced integration features.

// Like a chameleon, I adapt to all environments
@Inject 
@Qualified 
private SomeBean someBean;


Decoding @EJB

@EJB is a traditional, time-tested approach for injecting enterprise beans specifically. It supports EJB-specific features like beanName and handles certain complex cases that CDI alone may not.

// Rock, meet Hard Place - your EJB destination names
@EJB(lookup="java:global/myApp/myEJB")
private SomeEJBBean someEjbBean;


Opting for @EJB: When and Why

Consider @EJB when working with remote EJBs— it supports remote-specific metadata — or when you necessarily need to employ EJB services that @Inject can't replace. Examples of these are features like instance pooling for stateless beans or circular references suited for asynchronous calls and @PostConstruct.

// I may have commitment issues, but I always return to my EJB
@EJB 
private ShoppingCartBean shoppingCart;


Using @Produces for Advanced Cases

For cases where the transition from @EJB to @Inject needs to preserve the equivalent functionality, use @Producer. A @Produces annotation allows complex creation processes for beans and specification of metadata using qualifiers.

// Bean Maker 3000, your one-man army for bean creation
@Produces
@Qualified
public SomeBean produceQualifiedBean() { 
    // Code to create a specialized bean
    return new SomeBean();
}


The Superior Flexibility of @Inject

@Inject should be the go-to choice for modern Java EE projects due to its compatibility with the CDI specification and flexible choices. It effortlessly sails through qualifiers, alternatives, and interceptors — thereby allowing more control over bean management.

// Everyone loves a team player! On board the CDI train.
@Inject
@Any
private SomeBean someBean;


Areas of application

Legacy systems

In circumstances where your system is already heavily reliant on EJB, changing all code to @Inject might be unnecessary or even cause problems. @EJB is not outdated and offers unique functionalities that @Inject lacks.

Migration to CDI

If you're building a new application from scratch or seeking to modernize legacy systems with minimal dependencies on EJB, leaning towards @Inject might be an ideal choice. It can create a streamlined architecture that’s less dependent on EJB-specific server capabilities and is more ready for cloud environments.

Dealing with session beans

Remember the Session Bean Identity rule when assessing between @EJB and @Inject. An @EJB ensures consistent instance injection for stateless session beans, which can be crucial for certain use cases.

References

1. 23 Introduction to Contexts and Dependency Injection for Java EE (Release 7) — Official Oracle documentation on CDI in Java EE 7.
2. GitHub - weld/core: Weld, including integrations for Servlet containers and Java SE, examples and documentation — Source for Weld, the reference implementation for CDI.
3. Enterprise JavaBeans Technology — Official Oracle specification for Enterprise JavaBeans (EJB).
4. Java Dependency Injection - @Inject vs @EJB Performance Considerations — Comparing @Inject vs @EJB regarding performance.
5. The @EJB Annotation Explained - Baeldung Tutorial — A Baeldung tutorial on the @EJB annotation.