Java EE 5: Power and productivity with less complexity

An overview of Java EE 5 features and developer-productivity enhancements

Momentum for organizations to adopt Java™ Platform, Enterprise Edition 5 (Java EE 5) is steadily increasing as the platform's container support, developer tools, educational resources, and developer-community experience all improve. Get a high-level view of the new productivity features and API enhancements in Java EE 5 and work through a Web service example that demonstrates its simplified development models.


Scott Moore (, Senior Product Developer, BMC Software

Scott MooreScott Moore is a Senior Product Developer for BMC Software, by way of the RealOps, Inc. acquisition in July 2007. He is a Sun Certified Web Component Developer who has been working with Java EE technology for seven years, with a specialty in developing Web-based front ends for enterprise applications.

29 November 2007

Also available in Chinese Russian Japanese


Java EE technology is an extension to the Java language platform that enables you to create scalable, powerful, and portable enterprise applications. It defines four types of containers for application components: Web, Enterprise JavaBean (EJB), application client, and applet. These containers, and the Java APIs each must support, are detailed in an application-server specification that encourages a competitive marketplace for Java EE products while guaranteeing server portability for applications that adhere to the specification (see A brief history of Java EE).

The latest version of the platform, Java EE 5, was released in May 2006. Primarily focused on developer productivity, Java EE 5 brings simpler programming models without sacrificing any of the platform's power and richness. Two mechanisms — Java annotations and better defaults — are responsible for most of its simpler development models. Major functional improvements include enhanced Web services support and incorporation of JavaServer Faces (JSF) and the Java Standard Tag Library (JSTL) into the platform.

A brief history of Java EE

Java EE 5 was released by the Java Community Process as Java Specification Request 244, an "umbrella" JSR that refers to other specifications that detail its constituent technologies (see Resources). Specification Lead Bill Shannon of Sun Microsystems shepherded an Expert Group whose 31 members ranged from IT industry heavyweights to individual experts. Java EE 5's predecessors are:

  • J2EE 1.2 (released December 1999): This first J2EE release accompanied the release of Java 2 Standard Edition (J2SE). Its 10 specifications and APIs addressed common Web-tier, business-logic, persistence-layer, and messaging services needed by enterprise applications.
  • J2EE 1.3 (released September 2001): Released as JSR 58, this version improved half of the specifications in J2EE 1.2 and introduced an XML API, connector architecture, and security framework.
  • J2EE 1.4 (released November 2003): This version improved on 9 of the 13 technologies in J2EE 1.3 and introduced new support for Web services and security.

Java EE 5 immediately follows J2EE 1.4 because Sun has dropped "2" from the name (a relic from when Java 1.2 was rebranded as "Java 2"), and now uses the word "Java" rather than "J" in the technologies' shorthand names. The standard edition is now Java SE 6 (rather than J2SE 1.6), and the enterprise edition is Java EE 5 (rather than J2EE 1.5).

This article explores the features in Java EE 5, highlighting what's changed since the last J2EE release. (Enhancements beyond this article's scope include the addition of the StAX API — a pull-parsing API for XML — and small- to medium-sized improvements across many of the APIs.) I'll give you a comprehensive look at four feature categories: Web services, Web application, enterprise, and management and security. Then you'll "kick the tires" a bit, examining a small application that uses Java EE 5 features that demonstrate simpler development models for Web applications that use a service-oriented architecture (SOA).

The article is aimed at readers familiar with enterprise-level software systems who want a comprehensive, high-level view of Java EE 5. For the feature overview, a working knowledge of Java programming and J2EE is helpful but not necessary. The discussion of the example application dives into more-technical details that are probably more relevant to those with a J2EE (or at least Java programming) background.

Web services technologies

The introduction of annotations into Java EE 5 makes it simple to create sophisticated Web service endpoints and clients with less code and a shorter learning curve than was possible with earlier Java EE versions. Annotations — first introduced in Java SE 5 — are modifiers you can add to your code as metadata. They don't affect program semantics directly, but the compiler, development tools, and runtime libraries can process them to produce additional Java language source files, XML documents, or other artifacts and behavior that augment the code containing the annotations (see Resources). Later in the article, you'll see how you can easily turn a regular Java class into a Web service by adding simple annotations.

A leap forward in Web services support

The cornerstone of Web services support in Java EE 5 is JAX-WS 2.0, which is a follow-on to JAX-RPC 1.1. Both of these technologies let you create RESTful and SOAP-based Web services without dealing directly with the tedium of XML processing and data binding inherent to Web services. Developers are free to continue using JAX-RPC (which is still required of Java EE 5 containers), but migrating to JAX-WS is strongly recommended. Newcomers to Java Web services might as well skip JAX-RPC and head right for JAX-WS. That said, it's good to know that both of them support SOAP 1.1 over HTTP 1.1 and so are fully compatible: a JAX-WS Web services client can access a JAX-RPC Web services endpoint, and vice versa.

The advantages of JAX-WS over JAX-RPC are compelling. JAX-WS:

  • Supports the SOAP 1.2 standard (in addition to SOAP 1.1).
  • Supports XML over HTTP. You can bypass SOAP if you wish. (See the article "Use XML directly over HTTP for Web services (where appropriate)" for more information.)
  • Uses the Java Architecture for XML Binding (JAXB) for its data-mapping model. JAXB has complete support for XML schema and better performance (more on that in a moment).
  • Introduces a dynamic programming model for both server and client. The client model supports both a message-oriented and an asynchronous approach.
  • Supports Message Transmission Optimization Mechanism (MTOM), a W3C recommendation for optimizing the transmission and format of a SOAP message.
  • Upgrades Web services interoperability (WS-I) support. (It supports Basic Profile 1.1; JAX-WS supports only Basic Profile 1.0.)
  • Upgrades SOAP attachment support. (It uses the SOAP with Attachments API for Java [SAAJ] 1.3; JAX-WS supports only SAAJ 1.2.)

You can learn more about the differences by reading the article "JAX-RPC versus JAX-WS."

The wsimport tool in JAX-WS automatically handles many of the mundane details of Web service development and integrates easily into a build processes in a cross-platform manner, freeing you to focus on the application logic that implements or uses a service. It generates artifacts such as services, service endpoint interfaces (SEIs), asynchronous response code, exceptions based on WSDL faults, and Java classes bound to schema types by JAXB.

JAX-WS also enables high-performing Web services. See Resources for a link to an article ("Implementing High Performance Web Services Using JAX-WS 2.0") presenting a benchmark study of equivalent Web service implementations based on the new JAX-WS stack (which uses two other Web services features in Java EE 5 — JAXB and StAX) and a JAX-RPC stack available in J2EE 1.4. The study found 40% to 1000% performance increases with JAX-WS in various functional areas under different loads.

Web application technologies

Java EE 5 welcomes two major pieces of front-end technology — JSF and JSTL — into the specification to join the existing JavaServer Pages and Servlet specifications. JSF is a set of APIs that enable a component-based approach to user-interface development. JSTL is a set of tag libraries that support embedding procedural logic, access to JavaBeans, SQL commands, localized formatting instructions, and XML processing in JSPs. The most recent releases of JSF, JSTL, and JSP support a unified expression language (EL) that allows these technologies to integrate more easily (see Resources).

JSF 1.2

JSF has built-in support for common UI concerns such as component state management, event handling, navigation, user-input validation, and internationalization. Expert developers can create customized, powerful, reusable components or create custom renderers for client devices other than a Web browser. Less-technical users can reuse custom components, including the default JSF tag library for HTML interfaces, in visual programming environments such as Sun Java Studio Creator. This puts the creation of sophisticated Web presentation layers within reach of novice programmers.

A growing landscape of third-party JSF components exists in both the open source community and the licensed-software realm. You'll turn up dozens of options by searching for "JSF components" or "JSF component libraries" on the Web. Many of these components rely on Asynchronous JavaScript + XML (Ajax) techniques, which are a driving force behind the "Web 2.0" experience. Web programmers can use them to create applications that offer a better user experience than traditional Web applications, without needing to fuss with the details of writing Ajax components from scratch.

JSP 2.1

JSP technology has been around since J2EE 2.1. It leverages the Java Servlet specification to enable declarative programming of a UI. It supports programming UIs as documents that are translated into Java servlets, compiled, and invoked by the Web application container to service requests. These documents typically mix JSP directives and scriptlets with a presentation markup language such as HTML. JSPs can use an older syntax that relies on special tags that start with <% and end with %>, or on a newer syntax that is well-formed XML. They typically serve as the "View" part of a Model-View-Controller (MVC) UI framework.

JSP 2.1 and JSF 1.2 are more mutually compatible than prior releases, primarily because of the integration of their EL syntax into the unified EL. EL enables operations such as:

  • Accessing properties of JavaBeans in the request, session, and application contexts.
  • Performing logical tests that determine such choices as whether to hide or show a particular element.
  • Performing calculations that affect numbers and strings that appear in the UI.

In the past, there were differences in the JSP and JSF EL syntax and how the container evaluated them. The unified EL resolves these differences while also adding features such as:

  • A pluggable framework to enable customization of EL interpretation.
  • Support for deferred expressions that can be executed as needed by a JSP tag handler.
  • Support for assignment operations that can, for example, use an EL expression to set a property on a JavaBean from within JSP code.

A boon for JSP tag-library developers is that tag handlers now support resource injection using annotations, so tags that once required resource configuration and code to perform Java Naming and Directory Interface (JNDI) lookups can now be greatly simplified.

JSTL 1.2

JSTL has been around for years, but until Java EE 5, it existed outside of the Java EE umbrella. JSTL tags provide support for embedding the following types of elements in JSPs:

  • Procedural logic, such as loops and if/else switches.
  • Access to JavaBeans that can provide dynamic data to the UI or be modified by UI code.
  • SQL commands to perform database access.
  • Formatting instructions that format UI output according to specific locales.
  • XML processing, such as Document Object Model (DOM) parsing or Extensible Stylesheet Language (XSL) transformations.

JSTL 1.2 is a maintenance release that supports the unified EL and resolves issues that used to arise from trying to mix JSF tags and JSTL iteration tags in the same JSP page.

Java Servlet 2.5

The Java Servlet specification — the backbone of Java Web-tier technology — is as old as Java EE technology itself. The specification is designed to provide a high-performing, component-based approach to building Web applications that are portable across any servers that implement the specification.

The Servlet 2.5 specification required by Java EE 5 is a maintenance release that includes minor improvements over the 2.4 release. It introduces a dependency on the Java 5 platform along with some annotations that reduce the need for configuration in the Web application deployment descriptor (web.xml) configuration file. Additional configuration conveniences have been added, such as more-flexible servlet configuration with wildcarding and multiple url-pattern elements.

Enterprise application technologies

A lot of technologies fall under the enterprise application umbrella, many of which have not changed with the Java EE 5 release or are too detailed fall within this article's scope. I'll focus here on the two major improvements: ease of EJB development and new persistence features.

EJB 3.0

The EJB specification is core to the Java EE platform. It defines a way to encapsulate an application's business logic and distribute it in a highly scalable, secure, and transaction-aware way so that simultaneous data access doesn't result in corrupt data.

EJBs are of three basic types:

  • Session beans come in two flavors: stateless and stateful. Stateless session beans are used for business-logic tasks that service a single request from client code. Stateful session beans maintain a "conversational state" with the client and are good for sets of related tasks that span multiple client requests. Session beans cannot be shared among clients. Session beans typically operate on one or more entity beans.
  • Entity beans represent persistent data that is typically loaded from a database. Entity beans can be shared across clients, and the EJB specification provides transaction-safety mechanisms that ensure that entity beans can safely serve multiple, concurrent client requests without becoming corrupted. An entity bean can manage its own persistence or let the container manage it (container-managed persistence or CMP).
  • Message-driven beans (MDBs) serve requests from client code without forcing the client to wait for the response. They typically interact with a Java Message Service (JMS) queue — another enterprise application technology in Java EE 5 — but can also serve asynchronous clients, even ones not written in Java code, by other means.

In the past, EJB development has been complex and unwieldy, often forcing developers to rely on tools to manage the complexity of all the interfaces and deployment descriptors required to implement EJBs. It was invasive on the business-logic code, mandating that certain classes be extended or certain interfaces be implemented. Obtaining a simple reference to an EJB involved a lot of boilerplate code. These issues garnered EJB a bad reputation in the development community — in many cases, deservedly so.

EJB 3.0 represents a vast improvement in the EJB programming model and is one of the biggest potential sources of increased productivity for Java EE 5 developers. An EJB can now be an annotated "plain old Java object" (POJO) that doesn't need to extend a certain class. It only needs to implement a remote interface that you define or allow your IDE to create automatically. Deployment descriptors are no longer required because the EJB container can extract all it needs to know from the annotations on an EJB.

This article's Kicking the tires: The RideSynergy application section presents example code that provides concrete examples of these improvements. For readers thirsty for deeper details, you'll find links in Resources to two articles that offer compelling examples of how much EJB development has improved with the latest release.

Java Persistence API (JPA 1.0)

JPA introduces an object-relational mapping (ORM) framework for persisting Java objects. It was developed with EJBs in mind, but it can be used for any Java objects. Using annotations, you indicate which objects and fields are persistent and which database tables and columns they map to. JPA supports a rich query language that resembles SQL. The query language enables:

  • Definition of parameterized queries that can take parameters as an ordered list, referred to by index numbers, or as named parameters referred to by name.
  • Queries that traverse the relationships between persistent entities without requiring JOIN statements (though you can use JOIN statements if you prefer).
  • Typical SQL-like features to form search criteria (comparison operators, LIKE statements, BETWEEN statements, and so on) and define how to treat the result set (using operators such as DISTINCT, ORDER BY, GROUP BY, and so on.)

JPA brings new functionality to the Java EE platform, relieving many of the past headaches of roll-your-own or container-specific persistence approaches. The article "Design enterprise applications with the EJB 3.0 Java Persistence API" is a good starting point for learning more.

Management and security

Java EE 5 requires the same three management and security specifications that are available in prior versions:

  • Application Deployment provides an API for deploying components and applications to a Java EE container. Tools can access this API to deploy code to a Java EE 5 container without restarting the container. IDEs often use this API to enable rapid code/test/fix cycles during development.
  • Application Management specifies required attributes and operations of objects managed by the container. It's compatible with various industry-standard management protocols.
  • Authorization Contract for Containers (Java ACC) defines the semantics of security-policy providers and how to authorize access to operations managed within this contract. It requires that containers implement interfaces that enable deployment tools to manage authorization roles.

Each of these specifications in Java EE 5 is a maintenance release (each advances from version 1.0, introduced in J2EE 1.4, to version 1.1), with minor enhancements that are too detailed for this article's scope. Follow the Java EE Management and Security Technologies link in Resources for more information.

Kicking the tires: The RideSynergy application

This section presents a few examples of the simpler programming models in Java EE 5 that lead to increased developer productivity. You can see how these models enable rapid development of an example application that contains a Web service endpoint and client, uses EJBs for business logic, and uses JSF as a Web front end.

Java EE 5 on WAS CE 2.0

WebSphere® Application Server, Community Edition (WAS CE) version 2.0, is Java EE 5 certified. Read more about WAS CE and download it for free.

I'll demonstrate Java EE 5 technology using a simple Web application for an imaginary service called RideSynergy (see Downloads for the sample code). RideSynergy helps people meet online for the purpose of carpooling. I developed it using NetBeans 5.5 and tested it on both Sun Application Server 9.0_01 and WebSphere Application Server (Community Edition) 2.0.

Here how RideSynergy works:

  • It accepts ride offers and requests via a Web page.
  • If a ride is offered, it shows the user a list of matching ride requests.
  • If a ride is requested, it shows the user a list of matching ride offers.
  • As a convenience to the user, it offers the option of showing a weather forecast with the ride or offer results, because the weather might affect the user's choice of how to commute.
  • It offers statistics about offers and requests as a Web service to third-party applications.

A RideSynergy visitor uses the page shown in Figure 1 to offer or request a ride, specify a starting and ending ZIP code, and enter an e-mail address. The page also offers the option of seeing the local weather report.

Figure 1. RideSynergy offer-and-request page
RideSynergy offer and request page

If an offer was submitted, the results page (shown in Figure 2) lists any ride requests that match. If a request was submitted, then the matching offers are listed. The weather forecast appears only if the Check weather check box was checked on the offer-and-request page. (Note that in the actual application, the weather forecast shows five days of data. Figure 2 is cropped for brevity.) The weather-report data is retrieved from a publicly available Web service at

Figure 2. RideSynergy results page
RideSynergy results page

The code behind RideSynergy demonstrates Java EE 5's simpler Web service programming model: it uses JAX-WS for a Web service endpoint definition that includes an annotation, and it creates a Web service client with the wsimport feature. And it demonstrates both the simpler EJB programming model in Java EE 5 and the fundamentals of JSF.

Annotations: Doing more work with less code

The RideSynergy feature that offers rider statistics as a Web service is a compelling example of how Java EE 5 lets you do more with less code. This feature is implemented in the RideStatistics class, which demonstrates Java EE 5 annotations in their simplest form. But don't confuse simplicity for a lack of power: they show how much less complex Java EE 5's approach to implementing these features is than J2EE 1.4's.

The RideStatistics class in Listing 1 implements a Web service that uses the stateless RideManagerBean session bean to look up a count of ride offers made by RideSynergy users to and from ZIP codes specified by the Web service client. The RideManagerRemote interface defines operations on RideManagerBean that are available to client code, whether or not that code is runs in the same JVM.

Listing 1. The RideStatistics Web service
package com.ridesynergy;

import java.util.Set;
import javax.ejb.EJB;
import javax.jws.WebService;

 * Web Service that exposes a count of ride offers made to and from specific
 * ZIP codes.
 * @author smoore
public class RideStatistics {

   RideManagerRemote rideManager;

  /** Creates a new instance of RideStatistics */
  public RideStatistics() {

   public Integer rideOffersFromZipCode(Integer zipCode) {
      Set<Ride< results = rideManager.findCloseOfferMatches(zipCode, 0);
      return new Integer(results.size());

   public Integer rideOffersToZipCode(Integer zipCode) {
      Set<Ride< results = rideManager.findCloseOfferMatches(0, zipCode);
      return new Integer(results.size());

Listing 1 contains two annotations: @WebService and @EJB. First, I'll examine how the @EJB annotation enables the technique of dependency injection for accessing EJBs. Next, you'll see how the @WebService annotation enables a POJO to become a full-fledged Web service endpoint.

Dependency injection

If you are familiar with EJB programming in J2EE 1.4, you might look at Listing 1 and ask: Is getting a reference to an EJB really that easy? It is, because the @EJB annotation enables a simpler programming model based on dependency injection.

The @EJB annotation eliminates the need for code that in J2EE 1.4 would look something like Listing 2:

Listing 2: A pre-Java EE 5 RideManagerBean client
. . .
   Context initial = new InitialContext();
   Context myEnv = (Context) initial.lookup("java:comp/env");
   Object obj = myEnv.lookup("ejb/RideManager");
   RideManagerHome home = (RideManagerHome) PortableRemoteObject.narrow(
         obj, RideManagerRemote.class);
   RideManager manager = home.create();
. . .

In the EJB 3.0 programming model supported by Java EE 5, the @EJB annotation is said to inject the dependency that RideStatistics has on RideManagerRemote, rather than requiring that RideStatistics look up the reference using JNDI.

It also eliminates the need for a direct dependency on the package that contains RideManagerRemote. Look at the import statements; there's no import statement for RideManagerRemote (and yes, it does compile!). So RideManagerRemote could be refactored to a different package, and it would not force a need to update and recompile RideStatistics.

Annotations also bring many benefits to the other side of the dependency examined here: the actual EJB that provides the implementation behind RideManagerRemote and tells the Java EE 5 container what to do with it. I'll get to that in a moment.

Complex runtime behavior

When deployed to a Java EE 5 container, the @WebService annotation in Listing 1 is processed by JAX-WS and turns the RideStatistics class into a full-fledged Web service endpoint with two operations: rideOffersFromZipCode and rideOffersFromToZipCode. JAX-WS handles all the plumbing required to provide the Web service, including generating the Web Services Description Language (WSDL) that allows other applications on the Web to discover and use this Web service, and the mechanics of responding to client requests for the Web service.

The default location for the WSDL that JAX-WS produces for the RideStatistics Web service is http://server:port/ridesynergy2-war/RideStatisticsService?WSDL. To see this WSDL:

  1. Download the RideSynergy enterprise archive, ridesynergy2.ear (see Downloads) and deploy it to a Java EE 5 container.
  2. Replace the server and port values in the default location with your container's hostname and port.
  3. Load the location in a browser.

More-complex annotations

The annotations in Listing 1 are simple annotations. Annotations can also take named elements, which are similar to method parameters, except that the parameters' order and number don't matter because each one is named. Using named elements is like passing in a map to the annotation that contains key/value pairs that affect how the annotation is treated.

The WeatherForecastSoap interface (shown in Listing 3), which was created by the wsimport tool in JAX-WS, includes annotations that take named elements. Listing 3 shows the WeatherForecastSoap interface:

Listing 3: The WeatherForecastSoap interface
. . .  
   @WebMethod(operationName = "GetWeatherByZipCode", 
       action = "")
   public WeatherForecasts getWeatherByZipCode(
      @WebParam(name = "ZipCode", 
     targetNamespace = "")
     String zipCode);
. . .

Listing 3 shows a @WebMethod annotation on the getWeatherByZipCode() method that has two named elements: operationName and action. It also shows a @WebParam annotation on the zipCode parameter to getWeatherByZipCode() with the named elements name and targetNamespace. (Note that in the actual application, getWeatherByZipCode() has other annotations on it that I've omitted here for brevity.)

The code that defines the annotation specifies which named elements (if any) the annotation accepts. For details, refer to the Annotations primer link in Resources.

Declaring a stateless session bean

Listing 4 shows the class declaration for RideManagerBean, the stateless session bean that implements the RideManagerRemote interface used in Listing 1:

Listing 4: Stateless session bean declaration
. . .
public class RideManagerBean implements RideManagerRemote {
. . .

In J2EE 1.4, this EJB would have had to implement the SessionBean interface, requiring six method implementations. In many cases, these method implementations wind up empty and exist only to satisfy the interface and allow the code to compile, leading to cluttered code. EJB 3.0 does away with that mess by providing the life-cycle annotations @PostConstruct, @PreDestroy, @PostActivate, and @PrePassivate. You add these annotations as needed to any public, parameterless method that returns void to implement reactions to life-cycle events.

Annotations as replacements for deployment descriptors

Annotations in Java EE 5 also eliminate a lot of configuration code that prior Java EE versions require. For example, the @Stateless annotation in Listing 4 eliminates the need for an EJB deployment descriptor, which is an XML configuration file that provides the EJB details to the container. In previous Java EE platforms, such a descriptor would have been a part of an XML file that conforms to the EJB 2.1 schema. An excerpt for configuring RideManagerBean and its required interfaces would have looked something like Listing 5:

Listing 5: A pre-Java EE 5 deployment descriptor

Java EE 5 is backward-compatible with prior EJB deployment descriptors. You can even mix approaches if you wish, allowing legacy code to specify EJBs using descriptors while new EJBs are declared with annotations.

Aside from the reduction in the amount of code it takes to get the job done, annotations enable a maintenance benefit from what Sun architect Graham Hamilton refers to as "truth-in-source-code" (see Resources): With a properly annotated class, you don't need to look at both source code and configuration files to understand what is going on because the annotations that define special behavior are right there in the source code.

For a code-intensive review of many other examples of how annotations ease application development in Java EE 5, see Roland Barcia's article "Get to know Java EE 5."

Reasonable defaults

The fact that RideStatistics can become a Web service just by the addition of a single annotation also shows another Java EE 5 design principle in action: providing reasonable defaults to enable simpler programming models.

In this case, JAX-WS assumes that any public method in a class annotated with @WebService should be turned into a Web service operation that bears the same name as the method. Similar assumptions are made when the input and output parameters for these methods are processed. If you don't want the default behavior, you can always modify it by annotations on the methods. But in many cases, you'll probably want the terms used in the Web service to match terms used in the class that implements the Web service, and JAX-WS makes this easy to accomplish by providing reasonable defaults.


In the past, the benefits of Java EE technology have come only to those willing to wrestle with its complexity or tame it using development tools. It has earned a reputation as overly burdensome, a platform to consider only when a large, enterprise-grade system needs its powerful features and has the resources to deal with the development difficulty.

Java EE 5 seeks to shatter this reputation by leveraging new language features such as annotations, design goals such as reasonable defaults, and an emphasis on simpler programming models to provide an accessible, powerful platform for enterprise application development. Simpler programming models also make development shops less reliant on third-party tools to manage unnecessary complexity. The net result for people footing the bill is that it's now significantly less expensive to develop ever-more powerful enterprise applications. The net result for developers is that you can spend less time wrestling with the platform and more time impressing your managers with rapidly developed features built upon it.

Development shops that have shied away from Java EE technology in the past should give it a fresh look, and developers and maintainers of existing J2EE applications should explore Java EE 5 to discover the many ways it can make their lives easier.


Source code for the RideSynergy sample applicationj-jee5.zip10KB
RideSynergy enterprise archivej-jee5.ear10KB



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Java technology on developerWorks

Zone=Java technology
ArticleTitle=Java EE 5: Power and productivity with less complexity