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
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
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
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
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
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
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.
• An excellent and timely addition in JSF 2.0 is the built-in
CSS and the like. This includes the capability to refer to
resources via logical names, grouping resources into libraries and
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
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
• 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
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
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
• 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
• 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
• 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
• 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
• 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
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
• 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
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
• 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
• 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
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.