EJB 3.1 added a whole ton of features for simplicity and ease-of-use such as @Singleton, @Asynchronous, @Schedule, Portable JNDI name, EJBContainer.createEJBContainer, EJB 3.1 Lite, and many others. As part of Java EE 7, EJB 3.2 (JSR 345) is making progress and this blog will provide highlights from the work done so far. This release has been particularly kept small but include several minor improvements and tweaks for usability.

• More features in EJB.Lite
• Asynchronous session bean
• Non-persistent EJB Timer service
  
  This also means these features can be used in embeddable EJB container and there by improving testability of your application.
• Pruning - The following features were made Proposed Optional in Java EE 6 and are now made optional.
  
• EJB 2.1 and earlier Entity Bean Component Contract for CMP and BMP
  
• Client View of an EJB 2.1 and earlier Entity Bean
• EJB QL: Query Language for CMP Query Methods
• JAX-RPC-based Web Service Endpoints and Client View
  
  The optional features are moved to a separate document and as a result EJB specification is now split into Core and Optional documents. This allows the specification to be more readable and better organized.
  
• Updates and Improvements
  
• Transactional lifecycle callbacks in Stateful Session Beans, only for CMT. In EJB 3.1, the transaction context for lifecyle callback methods (@PostConstruct, @PreDestroy, @PostActivate, @PrePassivate) are defined as shown.
  
  

  	@PostConstruct	@PreDestroy	@PrePassivate	@PostActivate
  Stateless	Unspecified	Unspecified	N/A	N/A
  Stateful	Unspecified	Unspecified	Unspecified	Unspecified
  Singleton	Bean's transaction management type	Bean's transaction management type	N/A	N/A

  
  In EJB 3.2, stateful session bean lifecycle callback methods can opt-in to be transactional. These methods are then executed in a transaction context as shown.
  
  

  	@PostConstruct	@PreDestroy	@PrePassivate	@PostActivate
  Stateless	Unspecified	Unspecified	N/A	N/A
  Stateful	Bean's transaction management type	Bean's transaction management type	Bean's transaction management type	Bean's transaction management type
  Singleton	Bean's transaction management type	Bean's transaction management type	N/A	N/A

  
  For example, the following stateful session bean require a new transaction to be started for @PostConstruct and @PreDestroy lifecycle callback methods.
  
  

  @Stateful
  public class HelloBean {
     @PersistenceContext(type=PersistenceContextType.EXTENDED)
     private EntityManager em;

     @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
     @PostConstruct
     public void init() {
          myEntity = em.find(...);
     }
  
     @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
     @PostConstruct
     public void destroy() {
         em.flush();
     }
  }

  
  Notice, by default the lifecycle callback methods are not transactional for backwards compatibility. They need to be explicitly opt-in to be made transactional.
  
• Opt-out of passivation for stateful session bean - If your stateful session bean needs to stick around or it has non-serializable field then the bean can be opt-out of passivation as shown.
  
  

  @Stateful(passivationCapable=false)
  public class HelloBean {
      private NonSerializableType ref = ...
  
   . . .
  
  }

• Simplified the rules to define all local/remote views of the bean. For example, if the bean is defined as:
  

  @Stateless
  public class Bean implements Foo, Bar {
      . . .
  }

  where Foo and Bar have no annotations of their own, then Foo and Bar are exposed as local views of the bean. The bean may be explicitly marked @Local as
  

  @Local
  @Stateless
  public class Bean implements Foo, Bar {
      . . .
  }

  
  then this is the same behavior as explained above, i.e. Foo and Bar are local views.
  
  If the bean is marked @Remote as:
  

  @Remote
  @Stateless
  public class Bean implements Foo, Bar {
      . . .
  }

  then Foo and Bar are remote views. If an interface is marked @Local or @Remote then each interface need to be explicitly marked explicitly to be exposed as a view. For example:
  

  
  @Remote
  public interface Foo { . . . }
  
  @Stateless
  public class Bean implements Foo, Bar {
      . . .
  }

  only exposes one remote interface Foo.
  
  Section 4.9.7 from the specification provide more details about this feature.
  
• TimerService.getAllTimers is a newly added convenience API that returns all timers in the same bean. This is only for displaying the list of timers as the timer can only be canceled by its owner.
• Removed restriction to obtain the current class loader, and allow to use java.io package. This is handy if you want to do file access within your beans.
• JMS 2.0 alignment - A standard list of activation-config properties is now defined
  
• destinationLookup
• connectionFactoryLookup
• clientId
• subscriptionName
• shareSubscriptions
• Tons of other clarifications through out the spec. Appendix A provide a comprehensive list of changes since EJB 3.1.
• ThreadContext in Singleton is guaranteed to be thread-safe.
• Embeddable container implement Autocloseable.

A complete replay of Enterprise JavaBeans Today and Tomorrow from JavaOne 2012 can be seen here (click on CON4654_mp4_4654_001 in Media).

The specification is still evolving so the actual property or method names or their actual behavior may be different from the currently proposed ones.

Are there any improvements that you'd like to see in EJB 3.2 ? The EJB 3.2 Expert Group would love to hear your feedback. An Early Draft of the specification is available. The latest version of the specification can always be downloaded from here.

• Java EE 7 Specification Status
• EJB Specification Project
• JIRA of EJB Specification
  
• JSR Expert Group Discussion Archive
  

These features will start showing up in GlassFish 4 Promoted Builds soon.