Java EE 6 Overview
Reza Rahman, engineer at Caucho Technology, looks at the new features in Java EE 6.
Java EE 6 has all the makings of one of the best releases of the enterprise Java standard since its inception in the late nineties. Java EE 5 was without a doubt a revolutionary release. Java EE 6 straddles the line between being revolutionary and evolutionary. In the least, it solidifies the changes that began with Java EE 5. This brief article overviews the changes in Java EE 6, covers some of the API changes at a high level, mentions implementations currently available or underway and takes a forward look at the changes in Java EE 7 that are just being formulated.
Java EE 5 was a remarkable transformation for a mature, widely deployed, well supported development platform. EJB 3.0 was introduced as the reengineered business component development model, the aging EJB 2.x Entity Bean model was replaced by JPA as the persistence paradigm, JSF was introduced as the standard presentation tier framework and JAXWS 2.0 replaced JAX-RPC as the SOAP web services API. The focus of Java EE 5 was squarely on reducing complexity by embracing the concepts of annotations, POJO programming, zero-configuration systems, intelligent defaults and freedom from XML hell. Despite the reservations around Java EE in some camps, perhaps the best testament to the fact that Java EE 5 succeeded is the many folks who considered adopting Java EE for the first time because of these changes. A large number of these folks also comment on how surprisingly streamlined and well-put-together the Java EE programming model felt.
A Bird’s Eye View
Java EE 6 is another important step in the journey towards the ideal of a simple, streamlined and well-integrated platform. Java EE 6 also includes a rich set of innovations best reflected in the technologies that comprise the platform including brand new APIs like CDI 1.0 and JAX-RS 1.1 or even relatively mature APIs like Servlet 3.0.
Besides a few relatively minor changes such as standardizing global JNDI naming (which I won’t cover here), the major themes for Java EE 6 from a platform standpoint are pruning and profiles. In some ways, these themes are an essential byproduct of the deep seated changes in the platform. Let’s take a quick look at these changes.
Pruning the Dead Wood
The first release of Java EE was in 1999. By standards of the hypercompetitive technology industry, that’s nothing short of a lifetime. During this span, Java EE has only grown. As a result, the platform is now weighed down with some dead wood in the shape of APIs that are outdated, have been susuperseded, not well supported or not widely deployed. Java EE 6 begins the essential process of carefully pruning these APIs to make the platform more lightweight and to make room for healthier growth. Table 1 shows the APIs that are on the chopping block, along with an explanation of why. “Pruning” an API essentially means that an application server vendor need not support these technologies, although some larger vendors will probably continue supporting the pruned APIs for a period of time.
Profiles: Different Strokes for Different Folks
One of the major criticisms of Java EE has been that it is simply too large. Indeed, a majority of small to medium range Java web applications do not utilize the full Java EE stack. One can imagine the same to be true of SOA applications that would use features like messaging, transactions, persistence and web services but have no need for presentation tier technologies like JSP or JSF.
Profiles are designed to address this issue. Profiles are essentially sub-sets of Java EE APIs geared towards a particular class of applications in mind. For example, the Java EE 6 Web Profile only includes APIs that are likely to be used in most Java web applications. As such, the idea of Profiles has been used successfully in the standards world for a relatively long time. As you might already know, Java ME supports the idea of Profiles geared towards particular device runtime environments. Likewise, Profiles are used to better organize the increasingly complex world of web services standards such as the WS-I Basic Profile, the WS-I Basic Security Profile and the like. Although Java EE 6 defines the rules for creating new Profiles through separate JSRs, only one Profile, the Web Profile is included in the platform this time. Table 2 lists the APIs that are included in the Web Profile as opposed to the full platform:
Note that EJB Lite, and not the full version of the EJB specification is included in the Web Profile. I’ll describe EJB Lite in greater detail shortly.
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.
Java EE 6 Implementations
The unique power of Java EE lies in standardization, portability, compatibility and vendor independence. These unique values can only be realized if there are multiple high quality compatible Java EE implementations. Fortunately, Java EE 6 has been strongly adopted by a wide range of vendors – some familiar and some fresh. The table below lists the currently available implementations as well as the ones in the works
As you can see, there are an abundance of options to choose from despite some industry consolidation such as the Oracle purchase of Sun and BEA. In fact, Java EE 6 has been implemented more often and faster than any previous Java EE release. There are other application servers like SAP NetWeaver that I did not mention above since they have not yet formally announced their plans around Java EE 6 although they are very likely to support it in the near future.
A Look Ahead
Even as the Java EE 6 implementations roll in, the work for the next revision of Java EE is already being initiated. In the coming months, you should expect to see some of the first Java EE 7 JSRs. Here are some of the possible changes:
• Cloud support is a big part of Java EE 7. While it still isn’t clear exactly how Java EE 7 cloud support is going to look, the changes might include support for modularity, versioning, multi-tenancy and greater runtime security.
• A brand new API for Java EE concurrency will be added, similar to the concurrency utilities in Java SE.
• The JCache API will be updated and finally added to Java EE.
• The important concept of a simple managed bean was introduced in Java EE 6. In fact, EJBs were redefined to be managed beans with additional container services. You should expect this concept to be taken to the next logical step in allowing EJB services like pooling, transactions, locking, security, scheduling, asynchronous processing or even messaging to be available outside of EJB in plain managed beans (in fact, this is the model that Resin 4 embraces today and is supported by the Seam 3 persistence module as well). In addition, JSF, Servlets, JAX-RS and JAX-WS should offer greater alignment with managed beans. EJB 2.x CMP/BMP entity beans and JAX-RPC support in EJB should be deprecated.
• The next CDI release, CDI 1.1 should be relatively minor and include things like an embedded CDI container, enhancements to the portable extensions API and more XML configuration support. The real CDI related work should be better alignment of EJB, JPA, JSF, Servlet, JMS, JAX-RS and JAX-WS with CDI.
• JSF 2.2 will be a relatively minor enhancement with things like better portlet integration, Spring WebFlow/Oracle ADF style flow management and HTML 5 support.
• Servlet 3.1 will be a relatively minor enhancement with features like better Servlet async support for the new Java EE concurrency API and the emerging WebSocket standard.
• EL 3.0 will be separated from JSP as a pluggable API and include a few enhancements needed for CDI, JSF, etc.
• JPA 2.1 will be a minor update to add things like stored procedure support, further ORM flexibility, fetching flexibility, immutable attributes, read-only entities, update/ delete criteria queries, dynamic definition of persistence units and so on.
JAX-RS 2 will include a number of useful features such as a client API, better integration with the Bean Validation API, asynchronous request processing as well as being able to use JAX-RS resources as MVC controllers (with JSP pages being views).
• JMS will get a long-awaited revamp with JMS 2. JMS 2 could include more API simplifications, making JMS pluggable/ embeddable as well as better support for emerging Event-Driven Architecture paradigms.
• JTA 2 could be introduced to modernize the dated API as well as add better support for local transactions. Note some of this is from my own personal wish-list; if they sound right, feel free to support the idea via blogs, etc. Also, I encourage you to have an active voice in these changes by participating directly through the JCP.
The changes in Java EE 6 are compelling and have been largely well-received by the community. They include pruning, profiles, CDI, JSF 2, EJB 3.1, JPA 2, Servlet 3, JAX-RS and bean validation. If you have not taken a closer look at Java EE 6 yet, you owe it to yourself to do so now. There are a number of good Java EE 6 implementations available already with more on the way. In addition to simply being a passive user or evaluator of Java EE, you also have the opportunity to give your feedback towards Java EE 7 as the platform continues to evolve.