New Features in Java EE 6

ava Platform, Enterprise Edition version 6 (Java EE 6) is quite different from earlier versions. During its 10 years of development (2009 is J2EE/Java EE’s 10th anniversary), the platform has matured and grown vibrant by incorporating several APIs and technologies to make it more powerful and complete. However, the focus of Java EE 6 is ease of development and simplicity: that is, supporting all the technologies and frameworks from the enterprise Java community yet still continuing to simplify the platform.

This article discusses the goals for Java EE 6 and explores the new features it introduces: profiles, pruning, and extensibility. It also covers important technologies that have been updated in the release, such as Enterprise JavaBeans (EJB), Java Servlet, and Java Persistence API (JPA), explaining the changes introduced in them through some code examples. Finally, it will highlight two of the new APIs/technologies being introduced as part of the specification: Java API for RESTful Web Services (JAX-RS) and Java Contexts and Dependency Injection (JCDI, previously known as Web Beans).

Java EE 6 Goals

Ease of development was a major goal for the Java EE 5 release. Java EE 6 shares this goal with its emphasis on modularity and being lightweight. In fact, annotations are a major ease-of-development feature introduced Java EE 5 that Java EE 6 continues to support. However, the three main goals proposed for Java EE 6 are:

  • Extensibility: This mechanism provides a way to include additional technologies and frameworks that are not part of the standard platform. Extensibility points and Service Provider Interfaces (SPIs) help developers plug in these technologies to their platform implementations. Two new extensibility options are support for open-source enterprise application frameworks and scripting languages.
  • Figure 1. Web Profile in Java EE 6: Java EE Web Profile is designed for modern web application development.
  • Profiles: For building small- to medium-sized enterprise applications, the entire stack of Java EE APIs may be overkill. Enter Profiles, subsets of Java EE APIs targeting particular classes of applications such as financial, telecommunication, and so on. Profiles build on the standard Java EE platform technologies, sometimes using only a subset of those technologies, and sometimes adding Java technologies that are not part of the standard platform. The idea of profiles comes from various sources such as Java ME, where profiles are applied to specific device runtime environments, and web service standards like WS-I Basic Profile.
    Only one profile is slated for the Java EE 6 release, Java EE Web Profile, which is designed for modern web application development. Web Profile provides transaction processing, security, and persistence management for creating small- to medium-sized enterprise web applications. See Figure 1 for a depiction of Java EE 6 Web Profile technologies.The expert group is expecting community feedback to decide whether to include JCDI in the full platform and/or in the Web Profile.
  • Pruning: Pruning provides a way to remove the following technologies from the platform.
    • Java EE technologies that are outdated and have been replaced by new sets of technologies
    • Technologies that are not well supported
    • Technologies that are not widely deployed

    Developers can use pruning to mark these technologies for removal from the platform. Pruning means application server vendors will no longer have to support the pruned technologies, although they may choose to continue supporting them. Technologies such as Entity Beans and JAX-RPC, for example, are marked for pruning in Java EE 6. They can be pruned from the next version.

The following sections discuss some of the APIs that have undergone major changes in Java EE 6.

Enterprise JavaBeans 3.1

One of the main goals of the EJB 3.1 specification is to make EJB as simple as possible. The idea is to provide more emphasis on simplifying EJB architecture while introducing new functionalities. Some of the important changes in EJB 3.1 are:

  • Removal of local business interface: EJB 3.0 removed the complex home and remote interfaces and made way for the plain old Java interface (POJI). EJB 3.1 goes one step further by dictating that business interfaces also are not mandatory. Similar to POJOs such as entities in JPA and message-driven beans, developers can write session beans without business interfaces in Java EE 6:
    @Statelesspublic class StockQuoteBean {   public double getStockPrice(String symbol) {      ...   }}
  • Introduction of Singleton beans: The concept of Singleton beans was introduced primarily to share application-wide data and support concurrent access. When a bean is marked as a Singleton, the container guarantees a single instance per JVM that is shared across the application tier. This provision works well for caching. Singleton beans are like any other EJBs; they are POJOs that developers can mark as Singleton beans through annotations.
    All Singleton beans are transactional and thread safe by default, making way for flexible concurrency options. Java EE 6 also introduces concurrency annotations to perform locked read/write operations on getter and setter methods.
    @[email protected] class CounterBean {   private int count;   @PostConstruct   public void initialize() {      count=5;   }}
  • Packaging EJB components directly in a WAR file: One of the major advancements in EJB 3.1 is the option for including EJB in a WAR file directly instead of creating a separate JAR file. EJB 3.1 provides a simplified packaging mechanism for web applications, including EJBs. Figure 2 shows how packaging was done prior to EJB 3.1.
    With EJB 3.1, developers can place the EJBs directly under the classes directory in the WAR file, along with the servlets. Figure 3 shows packaging in EJB 3.1.

    Figure 2. Post List Page with Tags: This is how packaging was done prior to EJB 3.1.
     
    Figure 3. EJB 3.1 Packaging Structure: Here is packaging in EJB 3.1.
  • Embeddable API for executing EJB in Java SE environment: The idea behind this feature is to allow EJBs to run in Java SE environments; that is, the client and the EJB run in the same JVM. To run EJBs, Java EE 6 provides an embedded EJB container and uses JNDI for lookup. This is to facilitate better support for testing, batch processing, and using EJB from the desktop applications. The embeddable EJB container provides an environment to manage EJB. The environment supports a limited set of services. The javax.ejb.EJBContainer class represents an embeddable container.
  • Asynchronous Session Bean: A session bean can support asynchronous method invocations. Bean methods annotated with @Asynchronous are invoked asynchronously. Prior to EJB 3.1, any method invocation on a session bean was always synchronous.
    Asynchronous methods can return a Future object of the java.util.concurrent API. This will be useful for the client to get the status of the invocation, retrieve the return value of a method, check for an exception, or even cancel the invocation.
    Figure 4. EJB 3.1 Lite vs. EJB 3.1 Full: Here is a list of features supported in the full EJB API versus those supported in EJB Lite.
  • EJB Lite: The concept of profiles is applied to the EJB specification as well. Many enterprise applications do not require the complete set of features in EJB, so EJB Lite, a minimal subset of the EJB API, is introduced in EJB 3.1. EJB Lite includes all the features required for creating an enterprise application, but it excludes specialized APIs.
    EJB Lite provides vendors the option to implement a subset of the EJB APIs within their products. Applications created with EJB Lite can be deployed on any server that supports EJB technology, irrespective of whether it is full EJB or EJB Lite. Embeddable containers support EJB Lite.
    EJB Lite has the following subset of the EJB API:
    • Session bean components (Stateless, stateful, singleton session beans)
    • Supports only synchronous invocation
    • Container-managed and bean-managed transactions
    • Declarative and programmatic security
    • Interceptors
    • Support for deployment descriptor (ejb-jar.xml)

    The list of features supported in the full EJB API versus those supported in EJB Lite is shown in Figure 4.

Servlet 3.0

Servlet is one of the robust technologies in the Java EE APIs. Since its introduction, apart from the inclusion of filters and web application events, the Servlet specification has not undergone any major changes?until Servlet 3.0, which will introduce significant changes to the API.

Some of the major changes Servlet 3.0 will introduce are:

  • Support for Annotations: Instead of making an entry in a deployment descriptor (web.xml), developers can use annotations to mark a servlet. The annotation @WebServlet is used to mark a class that extends HttpServlet as a servlet in a web application. The @WebFilter annotation is used to mark a class that implements Filter as a filter in the web application. Similarly, developers can use annotations like @WebInitParam and @WebListener to specify an init parameter and a listener in a web application, respectively.
    With the introduction of annotations, the deployment descriptor web.xml becomes optional. Apart from these annotations, developers can continue to use other annotations related to security and dependency injection from the servlet or Filter.
    @WebServlet("/stockquote")public class StockQuoteServlet extends HttpServlet {   public void doGet(HttpServletRequest request, HttpServletResponse response) {      …   }   public void doPost(HttpServletRequest request, HttpServletResponse response) {      ...   }   ...} @WebServlet(name="StockQuoteServlet", urlPatterns={"/stockquote","/getQuote"})public class StockQuoteServlet extends HttpServlet {   public void doGet(HttpServletRequest request, HttpServletResponse response) {      ...   }   public void doPost(HttpServletRequest request, HttpServletResponse response) {      ...   }   ...} @WebFilter("/login")public class LoginFilter implements Filter {   public void doFilter(HttpServletRequest request, HttpServlerResponse response,  FilterChain filterChain) {      ...   }   ...}
  • Web fragments: Web fragments are meant to provide modularity. They provide logical partitioning of the deployment descriptor web.xml so that frameworks such as Struts and JavaServer Faces (JSF) can have their own piece of information added in the JAR file, and the developer doesn’t have to edit web.xml. Web fragments are identified by using web-fragment as the root element.
    Developers can use all the elements in the deployment descriptor. The only condition is that the root element must be and hence have the name web-fragment.xml. This element is typically placed in the WEB-INFlib folder. Any JAR file placed in the WEB-INFlib folder can include the web fragment, and it should have the structure META-INFweb-fragment.xml:
       StockQuoteServlet  com.stock.StockQuoteServlet com.stock.listener.StockAddedListener 

    When an application has multiple web fragments, the order of execution can be resolved using absolute ordering or relative ordering. In both cases, XML tags are used to identify the order. Absolute ordering is specified using in web.xml and relative ordering is specified using in web-fragment.xml.
    When the element is not mentioned or set to false in the deployment descriptor, the container skips processing web.xml and processes annotations and web fragments. If is set to true, then the container skips processing annotations and web fragments and processes based on the information available in web.xml, because this takes precedence.

  • Asynchronous processing: Servlets allow asynchronous processing in Java EE 6 to support AJAX. A servlet often has to wait for a response from a resource such as a database or a message connection. Asynchronous processing avoids the blocking request so that the thread can return and perform some other operation. Developers can mark servlets as asynchronous by setting the value true to the asyncSupported attribute of the @WebServlet or @WebFilter annotation. In addition to the annotation, some new APIs such as AsyncContext have been introduced, and methods such as startAsync have been added to the ServletRequest and ServletResponse classes.

JAX-RS 1.1 and JCDI 1.0

Java EE 6 includes the JAX-RS API, a new inclusion that provides a simple and easy way to create REST-based web services. JAX-RS fully supports REST principles, and provides POJO resources to which developers can add annotations to make them support REST. Due to the nature of HTTP, JAX-RS supports only stateless interactions. Sun provides a reference implementation for JAX-RS codenamed Jersey, which in addition to implementing the JAX-RS specification and providing good support for annotations, provides additional features not included in the specification.

Another notable new inclusion in Java EE 6 is JCDI. JCDI allows developers to bind Java EE components to lifecycle contexts, to inject these components, and to enable them to support loosely coupled communication. Java EE components can also fire and get notified of events with JCDI. The benefit is that different kinds of objects, such as EJB 3 session beans, POJOs, and Java EE resources, can all be injected. JCDI provides a good facility for integrating the web tier and Java EE enterprise services.

Java EE for a Larger Community

Java EE 6 provides many promising features that will truly make enterprise application development simple and easier. Features such as extensibility, profiles, and pruning will open Java EE up to a larger community. EJB 3.1 is more lightweight than its earlier versions and will see more adoption. The changes in Servlet 3.0 will make it more suitable for modern web application development, including AJAX. The concept of JCDI will be really helpful in frameworks like JSF, with the added advantage of support for annotations and AJAX.

Author’s Acknowledgements: The author would like to sincerely thank Mr. Subrahmanya VP, ECOM Research Group, E&R, for his ideas, guidance, support, and constant encouragement.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin

More From DevX