At Devoxx 2013, the tracks that I was most interested in were the Java SE and Java EE tracks, specifically in presentations about the new stuff in Java SE 8 and Java EE 7.
In this post, I’ll talk about the new features of Java EE 7.

As I already mentioned in my previous blog post, I attended 2 sessions on Java EE 7 this year. One by Java EE evangelists Arun Gupta and Antonio Goncalves during the University days and one by David Delabassee during the Conference. All of them gave a good overview on the new and updated specifications.

I’ll give you a broad overview on what Java EE 7 is all about and what it can mean for your day-to-day work.

History

First, I’ll explain the history of Java EE to describe where the platform is coming from:

It all started with Java EE 1.2 and 1.3 where the basic specifications were implemented: Servlet, JSP, EJB with CMP in Java EE 1.3 and JMS. Java EE 1.4 focused on web services development. Java EE 1.4 and older weren’t the most popular versions with Java developers. They were difficult, bloated and a lot of boilerplate code and XML configuration was necessary to implement the tiniest feature.
Java EE 5 made a complete 180° turn. Its focus was put on ease of development. The platform had to be easier in use and more fun to develop with. They succeeded!
Annotations were added to enable light-weight configuration of the application, much of the XML configuration was made redundant. EJB 3.0 was created, a much improved version of EJB 2.x. That specification was also used as a basis for new web services development. To simplify persistence, JPA emerged, a standardized version of popular ORM frameworks.
Java EE 6 made the platform even more configurable by introducting CDI, a standardized Contexts and Dependency Injection API. It fully implemented Restful Web Services and created a Java EE 6 Web Profile to enable light-weight fully managed web application development.

Because an image says more than a thousand words, Java EE 7 is all about these 3 big themes:

I’ll discuss these themes when I talk about the different specifications.

Specifications

Java EE 7 includes many updated and some new specifications:

CDI 1.1

CDI is now integrated into most Java EE specifications like JPA, EJB, Bean Validation, EventListeners etc. In the past, some specifications like EJB 3.x had their own dependency injection mechanism. In EJB 3.x you would use the @EJB annotation to inject EJB’s. Now you can also use CDI for that.

CDI is enabled by default. A beans.xml file is not necessary anymore, unless you want to override the new bean-discovery-mode option or other convention over configuration. The bean-discovery-mode option describes which beans will be discovered and injected automatically. You can specify the following values:

all: All types in the archive will be considered for discovery and injection.

annotated: Only types with bean defining annotations in the archive will be considered.

none: No beans in the archive will be considered.

You can use a new annotation: @Vetoed. Beans annotated with @Vetoed will not be discovered nor injected, regardless of the bean-discovery-mode configuration. It can be enabled on a per class basis, or for an entire package by annotating a package-info.java file.

Bean Validation 1.1

Bean Validation is integrated into more Java EE specifications like JAX-RS and JAXB. It’s not yet integrated into the SOAP API’s. You can also use Bean Validation in Java SE if you include the necessary Bean Validation provider on the classpath.

Talking about a cohesive integrated platform, CDI can now be used in Validator classes to inject dependencies.

Interceptors 1.2

Interceptors are also integrated into most Java EE specifications, except in the SOAP API’s.

New is the fact that you can associate interceptors with the instantiation of a class. You probably already know that the @AroundInvoke annotation exists. Now you can annotate methods with @AroundConstruct to perform certain functionality before and after a new instance of a class is created.

Interceptor ordering is supported. You can define interceptor priority using the @Priority annotation. Use the following values in descending priority order and add your own integer value to them to order your interceptors: PLATFORM_BEFORE, LIBRARY_BEFORE, APPLICATION, LIBRARY_AFTER and PLATFORM_AFTER

Concurrency Utilities 1.0

In the past, creating your own threads in a Java EE managed application was prohibited. The container took care of concurrency. You shouldn’t intervene in that or you could open the box of concurrency pandora.
Now Java EE 7 supports creating container managed threads yourself. You can use a ManagedExecutorService, ManagedScheduledExecutorService or ManagedThreadFactory for that. The executor or factory needs a Runnable or Callable instance as a parameter.

JPA 2.1

Schema generation has been standardized in Java EE 7. You can set the javax.persistence.schema-generation.database.action option in persistence.xml. Valid values are none, create, drop-and-create and drop. A validate or update setting doesn’t seem to exist (yet). Other options like loading data using SQL scripts are also standardized.

You can define additional indexes for schema generation in your code using the @Index annotation.

An unsynchronized persistence context is available now. When you use this type of persistence context, your changes are not flushed to the database until joinTransaction() is invoked. This way, you have more control of when the flush to the database occurs.

JTA 1.2

Transactional services that were used in EJB’s are now extracted to the JTA specification.
You can define transaction management on managed beans as CDI interceptor binding using the @Transactional annotation which seems to be coming straight out of Spring. You can specify on which exceptions the transaction should be rolled back, and which exceptions shouldn’t cause a rollback.

You can disable the passivation of stateful beans using the annotation @Stateful(passivationCapable = false). In some cases this can increase performance, scalability and robustness.

EJB 3.x Lite is a light-weight version of the full EJB 3.x API.
It supports EJB development, but doesn’t contain MDB’s, remoting or JAX-WS / JAX-RPC service endpoints. EJB 3.1 Lite didn’t contain asynchronous session beans nor timer services.
Now in EJB 3.2 Lite, local asynchronous invocations and a non-persistent EJB Timer Service are included. You can define an asynchronous method by annotating it with @Asynchronous. Timer Service methods can be scheduled using the annotation @Scheduled. You can use some kind of cron expression to define the scheduling.

JMS 2.0

The JMSContext API now supports a Builder Pattern style of programming.
Several JMS interfaces implement AutoCloseable so they can be used in try-with-resources blocks. And you can now define JMS Connection Factories and Destinations like queues and topics with annotations. You can find the comparison between the JMS 1.1 and JMS 2.0 API’s below.

Servlet 3.1

Servlet 3.1 supports non-blocking I/O. You can use this when processing large data sets in servlets. Several methods were added to existing interfaces and new interfaces were introduced: ReadListener and WriteListener. You can only use this in asynchronous servlets.

You can build richer protocols on top of HTTP by using the Servlet 3.1 protocol upgrade feature. This protocol upgrade is what HTML5 WebSockets use under the hood. A new HttpUpgradeHandler interface was created for this purpose.

By using the <deny-uncovered-http-methods /> tag in the application’s web.xml you can improve security of your applications. It does exactly what it says, deny all HTTP method requests for methods that aren’t covered in web.xml.

WebSocket 1.0

WebSockets are at the basis of HTML5. They enable full-duplex bi-directional communication over a single TCP connection. A good example of websocket usage is a chat client where several clients can post to and read messages of each other.

You can declare them programmatically as well by extending the Endpoint class. By extending the EndpointConfig classes ClientEndpointConfig or ServerEndpointConfig, you can modify your endpoint configuration.
You also have different lifecycle callbacks like @OnOpen, @OnClose and @OnError at your disposal.

You have the ability to create your own encoders and decoders of messages. I can best explain this with an example.

EL 3.0

Historically, Expression Language has been bundled under the JSP specification. Now that part is extracted to a separate updated specification. This way, you can use EL in a stand-alone environment to:

JSF 2.2

In JSF you now have a standardized version of Spring web-flow: Faces Flow!
You can define reusable flows in a XML and package them in a JAR. You can also build flows using annotations and a FlowBuilder. As you can see in the example below, you can use flows and @FlowScoped beans in EL. @FlowScoped beans only live during – as the annotation implies – the flow they were created in.

You can create reusable skins and themes using Resource Library Contracts.
JSF 2.2 now has better support for HTML pass-through attributes for HTML5-friendly markup and contains a File Upload component.

JAX-RS 2.0

Like the JMS 2.0 API, the JAX-RS 2.0 API brings you a more simplified programming model, using the Builder Pattern to invoke REST services.
You can also have asynchronous clients and servers. Restful clients work with Futures, restful servers work with suspended async responses.

You can process request and response headers by using message filters. New interfaces were created for this purpose: ClientRequestFilter, ClientResponseFilter, ContainerRequestFilter and ContainerResponseFilter. In a ClientRequestFilter implementation for example, you process the ClientRequestContext parameter to the filter() method.

Entity interceptors (not for JPA entities but JAX-RS messages!) can be used to marshal and unmarshal HTTP message bodies. For that, you have to implement the ReaderInterceptor.aroundReadFrom() and WriterInterceptor.aroundWriteTo() interface methods that take a ReaderInterceptorContext or WriterInterceptorContext respectively.

JSON-P 1.0

JSON-P is the JSON counterpart of JAXP that processes XML. You can use the new Streaming API for creating and parsing JSON. The Streaming API supports a Builder Pattern and is similar to the StAX API for XML processing.

With the JSON ObjectBuilder you create a JsonObject model in memory by adding elements.

Batch Applications 1.0

In batch applications, two styles of processing exist: chunk-style processing and batchlet-style processing.
Chunk-style processing is item-oriented. You process a batch of items at a time. A batch job contains one or more steps. A step contains chunks where a certain amount of items are processed. Every chunk is processed in a separate transaction. An ItemReader reads an item for the chunk that needs to be processed. An ItemProcessor processes the item that was read. At the end of the batch or the chunk, an ItemWriter writes the results to where you want them to go: a file, an e-mail, the database, … Abstract implementations already exist for these interfaces.
Batchlet-style processing is task-oriented. It doesn’t process items but does one specific task, like sending an e-mail. It is also part of a step. Your batchlet implementation class has to implement the Batchlet interface.

You can write listeners around specific phases of jobs, steps or chunks. You have to implement specific interfaces, or extend their respective abstract classes. The relevant interfaces are:

JobListener

StepListener

ChunkListener

ItemRead/Write/ProcessListener

SkipRead/Write/ProcessListener

RetryRead/Write/ProcessListener

The job definition is specified in an XML file. You can create partitions declaratively in XML or programmatically in Java to run job parts in parallel.
In the XML you can define the complete workflow. A flow consists of elements that execute together as a unit. You can define splits that support concurrent execution of several flows. In the XML you can also create decision paths to allow conditional continuation of the batch. For the XML decision, you have to write an implementation of the Decider interface that makes the decision and returns a String that refers to the path that needs to be followed.
An example of an XML job definition is this:

General

Over the entire platform, Java EE 7 now supports default resources, such as a default datasource, a default JMS factory etc. If you don’t specify a resource name for injection, the default resource will be injected.

@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;
// is the same as
@Resource
DataSource myDS;

All Sun-related namespaces are changed to xmlns.jcp.org and older specifications like EJB Entity Beans (CMP, BMP, EJB QL), JAX-RPC and JAXR are pruned from the new specification.

The Future

Of course, the Java world doesn’t end at Java EE 7. They are already looking forward to Java EE 8 for quite some time now. In Java EE 8, the focus will be on leveraging the platform in the cloud, standardizing PaaS to make cloud applications portable over different cloud providers. The specification leads will also continue to improve the platform and update it for HTML5, caching, NoSQL, polyglot programming and other trending topics.

Summary

As you have seen, a lot of new features were added to Java EE 7 that makes the platform more productive, easier to develop with and more future proof.
I hope you now have an overview on the new features of Java EE 7 so you can start looking around for some more information and try out the examples and the platform yourself.

I hope you enjoyed reading this blog post and that you have learned something new from it. Please be so kind to give your constructive feedback and comments below.

Before closing off, I would like to refer to the following sources where I took the liberty of getting the images and examples from:

Share this:

Like this:

LikeLoading...

Related

About Steve Schols

I am Steve Schols, a senior Java consultant working for several clients in Belgium.
I mainly blog about the Java language and relevant frameworks and technologies.
All statements made here are solely my own and do not represent the opinion of my employer, colleagues or my clients.