This content is part of the Conference Coverage: News from JavaOne 2015
News Stay informed about the latest enterprise technology news and product updates.

The highlights of Java EE 8

At JavaOne 2014, the latest features and upgrades of Java EE 8 were highlighted.

The new Java EE 8 upgrade promises a variety of changes and new capabilities for application developers and enterprise architects. At the JavaOne Conference in San Francisco this week, Li The new Java EE 8 upgrade promises a variety of changes and new capabilities for application developers and enterprise architects. At the JavaOne Conference in San Francisco this week, Linda DeMichiel, consulting member of the technical staff at Oracle, gave an overview of some of the key new features and the process that went into selecting them.

There have been many sources of input to Java EE 8 including Java users groups, community evangelists and most significantly a series of surveys put out to the Java development community. The survey was the largest and most comprehensive to date, and because of this was broken into three parts. The first two consisted of detailed questions and answers. The third survey gave participants the ability to prioritize features that rose to the top in the first two surveys. New APIs for JSON binding received the highest priority. Security simplification and security interceptors also ranked high. Other features that received slightly lower prioritization included support for a JCache API, a new model view controller (MVC) and Web tier enhancements.

Improving JSON binding

An API for JSON binding came in as the number-one priority with about 80% support from the community. This will make it easier to marshal and unmarshal data between POJO Java objects and JSON. The EE technical committee wanted to provide a default mapping to facilitate the data transformation and the ability to customize the mappings for different use cases. This is a relatively mature area in industry and there are a number of existing JSON binding implementations, such as MOXy and Jackson. DeMichiel observed it would be nice to provide plugability and switching between providers.

The idea is to facilitate mappings from the database to clients and then mapping for processing the return responses into JSON. This will allow JAX-RS to support JSON media types in a flashy way, but consistent with standards that will be comfortable to developers. One component of this process will be a JSON processing capability. The JSON processing API was a new technology introduced in EE 7. DeMichiel also said they would like to keep the JSON processing spec up to date. This will require introducing some editing operations to mutable objects.

JSON Patch is another standard in this space in which objects consist of operations that will be applied to target JSON documents to add, replace, move and copy text structure for updating fields in a string of text. JSON objects and JSON arrays are immutable. The editing capability will make it possible to implement JSON patch. One possible approach is to create a mutable copy of JSON objects into memory, which can be processed and then converted back into immutable JSON objects when done. DeMichiel said they would like to augment what they are offering with JSON to provide JSON specific collectors and collector operations to allow more sophisticated queries and constructs.

Another new technology planned for Java EE 8 is support for Server-Sent events. This technology will allow a client to establish a connection for long durations with the server that can be reused multiple times for sending event notifications. The Java EE planning committee ran into challenges finding the best home for this technology. The consensus was that JAX-RS was the most natural fit. The plan is to add a small extension to JAX-RS media output to the model on the server side. The client needs a new handler, which could be a simple JavaScript client. On the JAX-RS client view, the client registers a listener that will extract data from events.

Convoluted process to simplifying the MVC

The Java community also expressed considerable interest in a new MVC to be called MVC 1.0. This could complement the existing Java Server Faces as an architecture for creating Java applications. The Java EE process committee asked the Java community at large for sources of inspiration for implementing the new MVC. There were many proposals including a small majority that advocated leveraging the Spring MVC, and an even smaller group that recommended Angular or Play Framework MVCs. DeMichiel said there was no compelling response for any particular MVC framework to use as a model for Java MVC 1.0. The Java EE committee mulled this over for some time and began to look for a specific technology expert group to take the lead. The JAX-RS group was chosen first, but there was pushback.

So the initiative was reorganized under a separate group that is proposing a standalone API for an action-based MVC with the goal of leveraging key Java EE technologies for the MVC. The model will be based on CDI, Bean Validation and the Java Persistence API. The view will be based on Facelets and JavaServer Pages. The controller will be determined by the expert group. It is not clear if JAX-RS could be supported, but DeMichiel said they are expecting something new in terms of the controller technology.

DeMichiel recommends that developers who would like to participate in the Java EE 8 community process adopt a JSR.

Dig Deeper on Java ALM

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

I admit I do not have the most typical use case, but one of the things that strikes me as odd as someone new to JavaEE is how divergent and unintuitive it really all is.  Using Tomcat is totally different from Jetty which is different from ...  Then there is IDE -- IntelliJ does things different from how Eclipse does them.  Then there is the question of the build and if you will use the IDE, Ant or Maven to create the WAR file.  As someone who formerly did ASP.NET code, I just find the community rather fragmented.  While providing a new MVC method and new JSON is cool and useful, I wonder how accessible the community is to someone coming in to learn JavaEE?  Is building just for the community going to make things less accessible for beginners as you bolt on new options?    I do appreciate that sometimes you need more than one tool in your tool box, but will this new JSON library be the 'default' tool while you can get a specialized tool if needed or will it end up being that there are 8 big libraries for JSON rather than 7 that previously existed?