Skip to main content

Java EE 6 platform specification reaches Proposed Final Draft stage

Posted by robc on October 8, 2009 at 11:33 AM PDT

The Proposed Final Draft (PFD) of the Java EE 6 Platform specification and of the two other specs being defined by the JSR-316 expert group, the Java EE 6 Web Profile specification and the Managed Beans specification, is now available from the JCP web site.

The most important change since public review is that we have added JSR-330 (Dependency Injection for Java) and JSR-299 (CDI, Contexts and Dependency Injection for the Java EE Platform) as required components to the platform and the web profile, as I preannounced two months ago.

Attentive readers may have noticed that the Managed Beans specification is a new document; until now, JSR-316 had only produced two specifications. A natural question to ask at this point would be: "wait a minute, didn't we already have managed beans?" The answer is yes. We already had managed beans in JSF. We also had a notion of beans in CDI, one that encompassed plain beans (called "simple beans" in a draft of that specification) and EJB session beans. And of course EJB session beans can now be used outside of a Java EE application server, thanks to the introduction of EJB Lite. The platform expert group then agreed to put things in order and came up with a unified notion of a managed bean that could serve as a foundation for all the kinds of "beans" floating around in the platform, and more generally as a way to unify all the existing component models going forward.

For this plan to work, the definition of a managed bean must be sufficiently general to let different specifications build on it, and at the same time be meaningful enough to be usable in a practical way by developers. At the core, a managed bean is simply a Java class that is treated as a managed component by the container: It can have an optional name, and it can take advantage of a small, predefined number of services in Java EE, mostly related to lifecycle and resource injection (@PostConstruct, @PreDestroy, @Resource, ...). Other specifications can build on this basic definitions and add other services. So for example CDI adds interceptors, dependency injection (@Inject), scopes, etc. We also re-interpreted EJB session beans as being managed beans with added services, such as transactions, security, instance pooling, remoting, etc. Finally, we made it possible for most existing components in the platform to be managed beans, or, as I will explain below, for managed beans to be used as components of any given type.

Let me elaborate on this last point through an example. Given a JAX-RS resource class, you can turn it into a managed bean by adding a @ManagedBean annotation, or an EJB component annotation (@Stateful) or one of many potential CDI annotations (e.g. the @Default qualifier). What's more, one can also take the opposite view, and see the resulting class as coming from a managed bean or an EJB component that has been turned into a JAX-RS resource class by the addition of a JAX-RS @Path annotation. The same thing can be done with a servlet, or a JAX-WS endpoint class, or (mostly) any other component type in Java EE 6.

At a high level, the direction we're going in is one where the services made available by EE containers can be mixed and matched on any single bean, breaking down any rigid barriers, such as the traditional one between the "EJB world" and the "web world". In this respect, the newfound ability to define EJB component directly inside a web application can be seen simply as a way to let developers use managed beans of the EJB flavor inside the web container. Incidentally, I'm not claiming that we broke down every barrier and made available all container services to all beans yet -- some of that work will necessarily happen in a future release, especially in light of the compatibility issues that some of this mixing-and-matching can raise -- but I think that we delivered some genuine improvements to the model, all while operating a conceptual simplification of the platform and setting a strong direction going forward.

There are several other notable features in the PFDs: we introduced the new java:global, java:app, and java:module namespaces to go along the good old java:comp; we added Bean Validation 1.0 as a required component to both the full platform and the Web Profile, and made Validator and ValidatorFactory objects injectable using @Resource; we made it possible to portably declare resources of type DataSource either in code or via a deployment descriptor; we updated the versions of several other components to the latest ones (e.g. EL, JACC).

I'm looking forward to your comments on the draft. Please address them to javaee-spec-feedback<at>sun.com.

Related Topics >>