New Features in Java EE 6
Java EE 6 Overview - Part 2
A Fast Walk Around the Block
Thus far we've covered the work of the JSR 316 expert group, responsible for determining the overall make-up of the Java EE platform. While this work is critically important, most people associate Java EE with the individual APIs that compose the platform. In this section, let's take a quick look at the changes in the Java EE 6 APIs. I highly encourage you to dig further into each of these APIs on your own.
CDI 1.0: CDI is perhaps the most groundbreaking API developed in the Java EE 6 time-frame. CDI fills a number of important gaps in Java EE. Although CDI is inspired by Seam, Guice as well as Spring, it does not directly mirror any of them. Indeed, CDI adds a number of unique innovations of its own. Here is the long and short of what CDI offers:
• CDI unifies the JSF, JPA and EJB 3 programming models to truly feel like a single, well-integrated platform. It does this by registering EJB 3 beans, JPA entities as well as plain JavaBeans ("managed beans" in Java EE 6 parlance) as CDI components and making them accessible via EL as well as being injectable into each other. In effect, CDI lets you eliminate JSF backing beans and flatten the traditional application tiers if you want.
• CDI implicitly manages the life-cycle of all registered components in appropriate contexts. In addition to the traditional request, session and application centric component scopes, it adds the notion of an implicit "dependent" scope as well as a "conversation scope". While the dependent scope essentially "inherits" the invoker's scope, the "conversation scope" is based on the idea of application demarcated sessions based on stateful workflows. From an EJB 3.1 perspective, this bridges the gap between clientagnostic generic component scopes (stateless, stateful, shared) to Web application centric scopes.
• CDI brings a robust set of dependency injection features to the platform in a completely type-safe, annotation-driven and Java-centric way. These features include the ability to integrate arbitrary Java objects that are not EJBs, Servlets or otherwise managed objects, inject managed objects into non-managed objects, inject non-managed objects into managed objects, use object factories and utilize stereotypes to group annotations' metadata together to define altogether new component types.
CDI enhances the Java EE Interceptor model by adding the ability to bind interceptors to annotations instead of having to bind interceptors to target object classes themselves. The annotations bound to the interceptors are then placed on the target objects. Unlike the Java EE 5 model, this adds an indirection between interceptors and target objects. CDI also adds the very interesting concept of "decorators". In essence, decorators are interceptors that are aware of target business objects instead of being business domain agnostic.
As impressive as this list is, it is just the tip of the iceberg. CDI adds a lot of other very cool features that constitutes the next generation of integration features for Java EE. For example, CDI includes a type-safe event bus as well as a well-defined portable extensions API designed to encourage a rich CDI plug-in ecosystem to be seeded by projects like Seam 3. For a closer look at CDI, check out the final draft.
JSF 2.0: Despite the fact that the Java presentation tier framework market is fiercely competitive, JSF appears to be holding ground. However, there are a number of valid concerns around the usability and robustness of JSF. JSF 2.0 meets these concerns head-on by focusing on ease-of-use, innovation and expanding the feature set:
• JSF formally adds Facelets as a view technology. In case you are unfamiliar with Facelets, it is an open source view technology specifically developed with JSF in mind. As a result, unlike JSP, it fits the JSF component model and life-cycle a lot better. However, possibly the most powerful feature Facelets brings to the table is the ability to easily create custom components and templates without Java code and with mark-up instead. The complexity in creating custom components and templates is probably the biggest complaint against JSF.
• JSF 2.0 brings Java EE 5 style annotation-driven configuration to the table via annotations such as @ManagedBean and @ManagedProperty. This means a dramatic reduction in the size of the faces-config.xml file, although things like navigation rules will still need to be configured in XML.
• JSF 2.0 changes the JSF life-cycle to account for AJAX. This is done via introducing the concept of partial page processing to handle AJAX events. This enhancement makes developing AJAX capable JSF components feel more natural as opposed to feeling like you were trying to fit a square peg into a round hole.
Besides the list above, JSF 2.0 includes a number of other changes like adding support for events, bookmarking, URL parameter binding, RAILS_ENV style development stages and significantly expanding the standard set of components. You can check these out yourself by reading the JSF 2.0 final draft.
EJB 3.1: EJB underwent the most dramatic changes in Java EE 5. As much as it may have seemed impossible, EJB 3.0 was relatively well-received by the community and the adoption rate has been growing. It's probably an oversimplification to think just the changes in Java EE 5 caused this. For example, the interest around JBoss Seam and the vigorous development of GlassFish are probably important contributing factors. The main goal of EJB 3.1 is to continue down the path of making EJB as simple as possible while adding meaningful business component services. Here is a high-level overview of the EJB features:
• Business interfaces have been made optional even for Session Beans. This is particularly useful for using Session Beans in JSF with CDI.
• EJB 3.1 adds the concept of Singleton Beans. Because they are intended for managing shared application state, they are completely thread-safe by default. However, EJB 3.1 adds declarative concurrency controls for greater flexibility.
• A particularly powerful feature in EJB 3.1 is support for cron-style scheduling. In addition to the current interval based timer API, both declarative and programmatic cronstyle scheduling APIs were added.
• Another powerful feature added to EJB 3.1 is the capability to invoke Session Bean methods asynchronously via the @Asynchronous annotation. You can even control the asynchronous EJB method via a handle to a java.util.concurrent. Future object.
• The concept of EJB 3.1 Lite was introduced to add a smaller subset of the EJB API geared towards the Web Profile. While EJB Lite includes features like transactions and security, it does not include features like messaging, remoting and scheduling.
Besides the features in the list above, EJB 3.1 also adds the capability to package EJBs directly in WAR files, run an embedded EJB 3.1 container in Java SE environments such as JUnit tests (this capability powers CDI/Java EE centric testing projects like JBoss Arquillian) and utilize standardized global JNDI names for EJB. The EJB 3.1 final draft covers all these features in detail.
JPA 2.0: As of Java EE 6, JPA has been officially separated from EJB as a distinct API in its own right. There can be little doubt that JPA has been a success. It enjoys great adoption rates and first-class vendor support. That is no meager accomplishment for the persistence standard in Java EE considering the EJB 2.x Entity Beans meltdown. An important factor in this is probably the unequivocal support from Gavin King as well as the rest of the JBoss community. JPA 2.0 aims to build on this success by filling in a few much needed gaps as well as adding useful innovations:
JPA 2.0 adds a number of much needed ORM mapping enhancements such as the ability to model collections, maps and lists (that do not represent entity relationships) via the @ElementCollection annotation and the ability to map unidirectional one-to-many relationships (JPA 1.0 only allowed bidirectional one-to-many relationships.)
• Both the EntityManager and Query APIs have been enhanced to support things like retrieving the first result (JPA 1.0 allowed the retrieval of a unique result), specifying the maximum size of query results, getting access to the underlying vendor-specific entity manager/query objects and pessimistic locking (JPA 1.0 only supported optimistic locking).
• JPQL has been enhanced with SQL-like CASE, NULLIF, COALESCE and like capabilities.
• JPA 2.0 adds a Criteria API that many folks have been asking for. In case you are unfamiliar with the Criteria API in Hibernate or TopLink, it is essentially the object-oriented, type-safe, Java-centric equivalent of JPQL statements. This is a boon for use cases such as writing complex dynamic queries and avoiding runtime exceptions thrown while parsing JPQL.
There are a whole host of other features that JPA 2.0 adds such as standardizing second level caching, standard JDBC properties, specifying timeouts and the like. Feel free to take a look at these features detailed in the JPA 2.0 final draft available from the JSR site.
Servlet 3.0: Given the maturity of the venerable Servlet API, it can perhaps be somewhat surprising that it is going through a major revision. As a matter of fact, the Servlet 3.0 changes have generated quite a bit of excitement and is likely to be very well-received by the community. Here is an overview of the changes:
• Servlet 3.0 embraces the Java EE 5 model by introducing annotations such as @WebServlet, @ServletFilter and @WebServletContextListener. This significantly reduces web.xml configuration to the point that it could be eliminated altogether.
• Servlet 3.0 also introduces the idea of web.xml fragments. This means that the container looks for configuration in web.xml fragments anywhere in the web application classpath (such as the WEB-INF/classes directory or jars in the WEB-INF/lib directory) in addition to the web.xml file in WEB-INF directory. This is particularly useful for web application frameworks like JSF or Struts that need their own web.xml configuration to be bootstrapped.
• Another very cool addition is the ability to programmatically add Servlets, Filters and Listeners through the ServletContext. Like web.xml fragments, this feature is also primarily geared towards framework developers that need to dynamically determine configuration at runtime.
Besides the changes above, Servlet 3.0 also introduces features like asynchronous processing support. The Servlet 3.0 final draft is available here for you to take a look.
JAX-RS 1.1: REST is increasingly gaining traction as an alternative web services development paradigm. The inclusion of JAX-RS, the REST counterpart of JAX-WS, into Java EE is a nod to this trend. Much like JAX-WS abstracts away the low-level details of the SOAP protocol, JAX-RS is designed to reduce REST development to POJO programming and annotation based configuration. Here is a high level view of JAX-RS:
• The @Path annotation determines the URL that a JAX-RS resource can be accessed, down to a method in a POJO.
• Annotations like @GET, @POST, @PUT and @DELETE are used to specify the HTTP method that is used to access a resource.
• Input from sources like URL query parameters, parts of the URL, cookie values and HTTP header values are mapped into variables via annotations like @QueryParam, @PathParam, @CookieParam and @HeaderParam respectively.
• The @Produces annotation tells JAX-RS what the content type of returned values are such as text/xml, text/json and the like.
• JAX-RS is integrated with Servlets, CDI and EJB.
JAX-RS has many other powerful features that make REST development a breeze, much like JAX-WS makes SOAP development almost transparent. The final draft of JAX-RS is downloadable here.
Bean Validation 1.0: Although Bean Validation is not a component level API per se, it is possibly one of the most interesting innovations in Java EE 6. The Bean validation API allows you to enforce application validation rules or constraints (such as field not null, numeric value between 10 and 45, valid email, etc) in a declarative fashion only once across all the application tiers. The idea is that all frameworks that support Bean Validation would then transparently read and enforce constraint meta-data that you place on a bean (likely through annotations). Here is a high level view of the Bean Validation API:
• A simple bootstrap API that any supporting framework can use to locate the Bean Validation API and evaluate constraints as needed. As a Java EE developer, you would likely not be exposed to this low-level API.
• A set of built-in constraint annotations such as @NotNull, @Max, @Min, @Size, @Pattern, and so on.
• A way to group constraints to be validated at various stages of the application.
• Bean Validation is integrated with JSF 2 and JPA 2. Bean Validation has many powerful features such as the ability to create custom constraints and validators. The final draft of the Bean Validation API is downloadable here.