Java EE 7 at a glance

by Markus Eisele

Around three and a half years have passed since the last major version jump of the Java Enterprise Edition (Java EE). It was intended that Java EE 6, which was designed with developer performance and simplification in mind, would become technologically more powerful in Java EE 7 through the addition of cloud support. These plans proved too ambitions at quite a late stage. As a result, the version that was completed in mid-April contains very few fundamentally new aspects and just represents a consistent effort to round off existing features.

Java Enterprise Edition 7 is the first version that has been created solely under Oracle's sponsorship. The "umbrella" specification includes a multitude of individual technologies and provides the basic framework for the cooperation between them. One of the main aims since the introduction of the Java EE platform has been to take care of general infrastructure tasks for developers – this functionality is provided by a container model that abstracts and simplifies resource access and management. The container APIs have been simplified over the years, and Java EE 7 continues this trend. Resource definitions have been extended, and application servers now provide a preconfigured standard database and a JMS ConnectionFactory. This will likely simplify development and save programmers a lot of configuration work.

Four completely new specifications have been added to Java EE 6's 28 specifications and major enhancements that justify a big version jump have been added to three existing specifications. For the remaining specifications, the developers have mainly done model upgrading with maintenance releases. The Java EE 6 specifications that were designated to be removed have been classed as "optional" and server vendors are, therefore, no longer obliged to implement them (EJB Entity Beans, JAX-RPC 1.1, JAXR 1.0 and Java EE Application Deployment 1.2).

New additions include APIs for working with popular web technologies. The expert groups have added full specifications for technologies such as WebSockets (JSR 356) and JSON (JSR 353) and provided HTML5 support for JavaServer Faces (JSF). Batch processing has also become part of the platform. JSR 352 standardises a programming model for batch applications and offers a runtime environment for planning and executing the relevant tasks. The Concurrency Utilities provide improved access to container resources, and using the API now offers the opportunity to work with threads in Java EE with reliably synchronised containers.

The most important changes at a glance.

Next step in the Web Services evolution

Although JAX-RS was available in the previous version of Java EE, the Java API for RESTful Web Services (JAX-RS) 2.0 includes important new features that justify a big version jump. The most noteworthy characteristic is the new client API that allows endpoints to be accessed directly from within any Java application. Third-party libraries will, therefore, no longer be necessary. The following example creates a new client and formulates a request with two parameters to send against the server endpoint.

Client client = ClientFactory.newClient();
String name = client.target("/category/{number}/name")
                    .resolveTemplate("number", "5")
                    .queryParam("humanReadable", "true")
                    .request()
                    .get(String.class);

A new addition is the asynchronous processing of requests between clients and servers. In the style of the asynchronous features introduced with Servlet 3.0, these requests are now handled via AsyncRequest:

@GET
@Produces("application/plain")
public void longRunning(@Suspended final AsyncResponse ar) {
    Executors.newSingleThreadExecutor().submit(
            new Runnable() {
        @Override
        public void run() {
            longRunning();
            ar.resume("Hello The H Developer!");
        }
    });
}

Message filters and entity interceptors enable developers to access requests and responses and process them on the server side. Filters also provide an elegant way for developers to implement other aspects such as logging.

@Provider
class LoggingFilter implements RequestFilter {

 @Override
 public FilterAction preFilter(FilterContext context) throws IOException {
             log(ctx.getRequest());
             return FilterAction.NEXT;
 }
 //...
}

This needs to be bound via an @Qualifier, and then it can be directly used with a JAX-RS resource:

@Logged
@GET
@Produces("text/plain")
@Path("/hello")
public String hello(){
    return "Hello @honline!";
}

This makes working with built-in classes such as String comparatively easy. Where custom objects are used, the mapping between these objects and their serialised versions (JSON, XML) must be done manually. The specification provides the required technical capabilities using "entity providers" that enable developers to convert the message payload from one format into the other. The two associated APIs have been named MessageBodyReader and MessageBodyWriter accordingly. A reader for a fictitious "Person" object would look like this:

@Provider
@Produces("application/json")
public class PersonReader implements MessageBodyReader<Person> {
//...

 @Override
 public void readFrom(Person p, Class<Person> type, Type t, Annotation 
    as, MediaType mt, MultivaluedMap<String, Object> mm, OutputStream out)
         throws IOException, WebApplicationException {
  //...
 }

The entity providers only contribute the access to the developer hooks into JAX-RS, so the actual object serialisation and deserialisation must be implemented separately. Unfortunately, neither the specification nor the reference implementation provide standardised ways of doing so. Developers can either choose from existing mechanisms such as EclipseLink's MOXy or they can get busy themselves.

Next page: JSON, JSF, Servlets, bean validation

1 2 3 4 5 next »

Print Version | Permalink: http://h-online.com/-1889207