Java EE 6 Overview

A Quick Glance Back

Java EE 5 was a remarkable transformation for a mature, widely deployed, well supported server-side 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 JAX-WS 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 and freedom from XML hell. Despite the reservations around Java EE, perhaps the best testament to the fact that Java EE 5 has succeeded is the many folks that say they have considered adopting Java EE for the first time because of these changes. A large number of these folks also comment on how surprisingly streamlined the Java EE programming model feels.

A Bird’s Eye View

Java EE 6 is another big 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 WebBeans 1.0 and JAX-RS 1.1 or even 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 JSR 316 are pruning and profiles. Let’s take a quick look at these changes. For further details, I encourage you to check out the public review draft. It is available here: http://jcp.org/en/jsr/detail?id=316.

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 weighted down with some dead wood in the shape of APIs that are outdated, 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 currently on the chopping block, along with an explanation of why.

Table 1: APIs Pruned in Java EE 6

“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 time.

What are your thoughts on the pruning process? Is it too aggressive? Too conservative? Do you use any of the APIs above? Are there others APIs you believe should also be pruned?

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 proposed Java EE Web Profile will only include 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 platform this time. Table 2 lists the APIs that are included in the Web Profile as opposed to the full platform:

Table 2: Java EE 6 Web Profile

The reason the WebBeans entry in the table has a question mark is that it is still not certain whether WebBeans should be included in Java EE 6. The major concerns around WebBeans center on how it fits into Java EE overall, as well as whether the JSR technical content is modularized correctly. What are your thoughts on this? In case you are unfamiliar with WebBeans, I’ll talk about it in a bit more detail in the following sections. Should WebBeans be included in Java EE 6 in its current form? If not, what changes could be made to the JSR? Note also 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 too.

What do you think about the idea of Profiles in Java EE? Would lighter weight application servers conforming to a Profile be useful to you? How about the contents of the Web Profile? Is it too minimal? Too large? Just right? Is one initial Profile (in addition to the full platform) sufficient or should other Profiles be defined in Java EE 6? Should an even more minimal “Java EE Basic Profile” be considered?

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 and we would love to hear from you on the issues mentioned above, 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. While I think you will like what you see, all of these APIs can benefit from your timely feedback too.

WebBeans 1.0:

WebBeans is perhaps the most groundbreaking API developed in the Java EE 6 time-frame. WebBeans fills a number of gaps in Java EE. Although WebBeans is inspired by Seam, Google Guice as well as Spring, it does not directly mirror any of them. Indeed, WebBeans adds a number of unique innovations of its own. Both Gavin King of JBoss/Red Hat and Bob Lee of Google have been behind WebBeans. Here is the long and short of what WebBeans offers:

• WebBeans 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 as WebBeans components and making the accessible via EL as well as being injectable into each other. In effect, WebBeans lets you eliminate JSF backing beans and flatten the traditional application tiers if you want.
• WebBeans 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 client-agnostic generic component scopes (stateless, stateful, shared) to Web application centric scopes.
• WebBeans brings a robust set of dependency injection features to the platform in a completely type-safe and Java-centric way. These features include the ability to integrate arbitrary Java objects that are not EJBs, Servlets or other-wise managed objects, inject managed objects into non-managed objects, inject non-managed objects into managed objects, use object factories, specify the component deployment environment and utilize stereotypes to group annotations metadata together.
• WebBeans 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. WebBeans 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. WebBeans adds a lot of other very cool features that constitutes the next generation of integration features for Java EE. For a closer look at WebBeans, check out the public draft at http://jcp.org/en/jsr/detail?id=299.

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 without Java code and with mark-up instead. The complexity in creating custom components 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 should make developing AJAX capable JSF components feel a more natural.
• An excellent and timely addition in JSF 2.0 is the built-in capability to handle resources such as images, JavaScript files, CSS and the like. This includes the capability to refer to resources via logical names, grouping resources into libraries and versioning.

Besides the list above, JSF 2.0 includes a number of other changes like adding support for events, 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 public draft at http://jcp.org/en/jsr/detail?id=314.

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 3.1 features:

• Business interfaces have been made optional even for Session Beans. This is particularly useful for using Session Beans in JSF with WebBeans.
• 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 cron-style 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 and utilize standardized global JNDI names for EJB. The EJB 3.1 public draft covers all these features in detail: http://jcp.org/en/jsr/detail?id=318.

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 filing 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 public draft available from the JSR site: http://jcp.org/en/jsr/detail?id=317.

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 of 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 public draft is available here for you to take a look at: http://jcp.org/en/jsr/detail?id=315.

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, WebBeans 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 public draft of JAX-RS is downloadable here: http://jcp.org/en/jsr/detail?id=311.

Your Help is Needed

As you might be able to see, the expert group is trying hard to evolve Java EE into a powerful platform that is a pleasure to work with. Besides the innovations in the APIs that make up Java EE 6, the changes proposed by the JSR 316 expert group are both deep and broad. However, we can only go so far on our own. We need your feedback to tell us if we are on the right track or if we should be pursuing other paths. You can send your feedback directly to the expert group at [email protected]. Do feel free to copy me at [email protected] if you like.

Wish us luck and I look forward to hearing from you!

References

1. Java EE 6 Platform Public Review, http://weblogs.java.net/blog/robc/archive/2009/01/java_ee_6_platf_1.html.
2. Profiles in the Java EE 6 Platform, http://weblogs.java.net/blog/robc/archive/2008/02/profiles_in_the_1.html.
3. Web Beans Sneak Peek Part I: Introducing Web Beans, http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIntroducingWebBeans.
4. Web Beans Sneak Peek Part II: Injection, binding annotations and component types, http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIInjectionBindingAnnotationsAndComponentTypes.
5. Web Beans Sneak Peek Part III: Declaring components using XML, http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIIDeclaringComponentsUsingXML.
6. Web Beans Sneak Peek Part IV: Scopes, contexts and resolver methods, http://in.relation.to/Bloggers/WebBeansSneakPeekPartIVScopesContextsAndResolverMethods.
7. JSF 2.0 New Feature Preview Series (Part 1): ProjectStage, http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2.
8. JSF 2.0 New Feature Preview Series (Part 2.1): Resources, http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature5.
9. JSF 2.0 New Feature Preview Series (Part 2.2): Resources, http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature.
10. JSF 2.0 New Feature Preview Series (Part 2.3): Resources, http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature3.
11. JSF 2.0 New Feature Preview Series (Part 3): Publish/Subscribe Event System, http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature1.
12. JSF 2.0 New Feature Preview Series (Part 4): Resource Re-location, http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature4.
13. New Features in EJB 3.1, https://www.theserverside.com/news/1363656/New-Features-in-EJB-31.
14. New Features in EJB 3.1 - Part 2, https://www.theserverside.com/news/1363655/New-Features-in-EJB-31-Part-2.
15. New Features in EJB 3.1 - Part 3, https://www.theserverside.com/news/1363655/New-Features-in-EJB-31-Part-2-3.
16. New Features in EJB 3.1 – Part 4, https://www.theserverside.com/news/1363651/New-Features-in-EJB-31-Part-4.
17. New Features in EJB 3.1 – Part 5, https://www.theserverside.com/news/1363649/New-Features-in-EJB-31-Part-5.
18. An Overview of Servlet 3.0, http://java.dzone.com/articles/an-overview-servlet-30.