by Janice J. Heiss
Oracle Java EE Expert Arun Gupta provides glimpses into Java EE 7.
Published February 2013
At the annual IOUC (International Oracle User Community) Summit, held January 14–16, 2013, at Oracle headquarters in Redwood Shores, California, more than 100 top user group leaders from around the world gathered to share best practices, provide feedback, and receive updates from leading Oracle developers.
Of particular note was a session by Oracle Java evangelist and Java EE expert Arun Gupta entitled "The Java EE 7 Platform: Higher Productivity and Embracing HTML5," which offered a window into the rich possibilities that will be available in Java EE 7 upon its release in the spring of 2013. Gupta took the attendees through some major developments in Java EE 7:
In addition, he discussed the implementation status of Java EE 7, looked ahead to Java EE 8, and addressed the challenges and potential pitfalls involved in establishing a standards-based cloud programming model.
Gupta began the session with a brief discussion of Java EE 6, released on December 10, 2009. The intervening years have seen more than 50 million Java EE 6 component downloads, establishing it as the world's premier application development platform. The success of Java EE 6 constitutes the fastest implementation of a Java EE release thus far.
"In addition to Oracle, companies such as IBM, SAP, Hitachi, Red Hat, Fujitsu, and Caucho have adopted it," said Gupta. "There are 18 implementations of compliant Java EE 6 application servers today. Every month or so, we see a new vendor coming in."
He pointed out that Java EE 7 offers higher productivity; less boilerplate; richer functionality; more default options; and HTML5 support in the form of WebSocket and JSON. Although Java EE 7 offers a standards-based platform with a lot of innovation, Gupta observed, "There are not enough standards in the cloud with W3C and other standards bodies. More standards are needed so that we can define a Java API for the cloud. Premature standardization can also be a problem if not enough innovation has taken place. So what is the right thing for the platform? We have reached out to the community, the core group members, and the executive committee of the Java Community Process and have focused on providing higher productivity and on embracing the HTML5 platform more closely. We are going to use dependency injection a lot more, which will give developers the ability to write less boilerplate code and offer richer functionality such as batch applications and caching. Similarly, for HTML5, we are embracing WebSocket functionality and the ability to parse and generate a JSON structure. We are providing support for HTML5-friendly markup as part of JSF."
He then discussed the most important features of Java EE 7.
"We are building several new features in JAX-RS 1.0," explained Gupta. "We are introducing a new client API in 2.0 that will enable you to invoke a REST endpoint in a standard way. We are providing extension points, methods filters, and entity interceptors that improve how to do request and response and how to do pre- and postprocessing very easily, which will be useful in addressing cross-cutting concerns such as logging or security, which you can easily do as part of your REST endpoint."
Other new developments include asynchronous processing for both the server and the client, enabling more-scalable applications, hypermedia support, common configuration to simplify the REST endpoint, and more.
For more on JAX-RS 2.0, check out Gupta's blog entry on this topic.
Gupta pointed out that the last version of Java Message Service was released in December 2003—before JDK 1.4. Although JMS is stable and extensively used, he explained that it needed to catch up with subsequent changes in the Java platform such as generics, injection, and annotation. Java EE 7 leverages the new functionality to improve the way developers write JMS code. With JMS 2.0, developers will use less boilerplate code and will be able to take advantage of resource injection, meaning greater functionality and more-effective, simpler code.
Gupta demonstrated how it took 20 lines to send a simple message with JMS 1.1 whereas with JMS 2.0, it could be done in 6 lines with cleaner and more semantically readable code. "This is a huge improvement," he remarked.
Gupta turned to Java API for JSON Processing 1.0. whose original purpose was to parse and generate JSON when it was first introduced into the platform. Gupta remarked, "If you are familiar with JAXP, you know that it has an event-driven StAX streaming API and a DOM-based API. The same analogy applies to Java API for JSON Processing: it has a streaming API and an object API."
"What has been missing," said Gupta, "is the ability to take a POJO and place an annotation so that it will automatically do the binding for you as in JAXB. This improvement is forthcoming."
JSR 356 defines how to write a standards-based WebSocket application. It defines not just the service endpoint but also ways it can be written with either an annotation-driven or an interface-driven model. A separate client-side API will be introduced as well.
"The WebSocket protocol works by having everything on the wire functioning as a data or control frame," explained Gupta. "So an API or an SPI for data frames can be defined, enabling developers to manipulate the data frames. For example, you can use the SPIs to perform some WebSocket extensions for things such as compression or multiplexing. We are often asked how this can work in a Java SE environment. Whether it gets defined and approved in JSR 356 is to be determined. But Tyrus, the reference implementation for JSR 356, will provide a client profile."
Gupta explained that Bean Validation was a new specification introduced in Java EE 6. Instead of defining validation constraints—such as the number of characters allowed in a name or the number of elements in a list—as part of the application logic, they could be more easily defined with annotation. "An annotation," said Gupta, "is put as a constraint on a method, and the Bean Validator, which is part of Java EE, automatically kicks in and honors those constraints."
He explained that constraints can be defined at one point and are automatically honored by the Bean Validator; they can be enabled, disabled, configured, or defined as custom constraints. "In Java EE 6, this was used primarily by Java Persistence API and JavaServer Faces," Gupta remarked. "In Java EE 7, they can be put on EJBs or simple POJOs."
JSR 352 offers new functionality in Java EE 7 for non-interactive, bulk-oriented, long-running tasks such as generating monthly bank statements, which involves processing thousands of accounts in the short processing time of the bank's network. "You just define a process, and it runs by itself on schedule," said Gupta. "Most of the concepts of JSR 352 are borrowed from Spring. Tasks can be run in parallel or sequentially. There is a full Java XML that will define what your task will look like, with defined steps and a complete task flow."
Gupta commented that JSR 236 was filed a long time ago and has recently gained momentum. It defines how you can create, for example, new managed threads. Java EE itself restricts the creation of new threads. Java EE is a managed application, so if the user creates new threads and the container and the runtime have no knowledge of those threads, how does it manage it? JSR 236 will enable developers to create managed threads that are known and managed by the container.
Reusable flows, HTML5-friendly markup, and resource library contracts are the big-ticket items for JSF 2.2. Faces Flow borrows core concepts from Oracle ADF Task Flow, Spring Web Flow, and Apache MyFaces CODI. It introduces
@FlowScoped CDI annotation, for flow local storage, and
@FlowDefinition, for defining the flow with CDI producer methods. There are clearly defined entry and exit points with well-defined parameters, so the flow can be reused.
Gupta closed the session with a brief discussion of the minor changes offered by Servlet 3.1 and Java Persistence API 2.1. He pointed out that although the changes in Java EE 7 for these are minor, they each received major overhauls in Java EE 6.
Gupta encouraged developers to participate in Adopt-a-JSR, where they can pursue their interest in particular Java EE 7 JSRs and download code, play with it, report bugs, and offer feedback to Java EE 7 specification leads.
Janice J. Heiss is the Java acquisitions editor at Oracle and a technology editor at Java Magazine.