The Java Community Process (JCP) machinery has started cranking on Java EE again, a little over a year after Java EE 7 was released. The goal is to create the next major version of Java Enterprise Edition. Meet Java EE 8 and JSR 366!
This release is going to build upon the highly successful previous release of the platform, with the addition of lots of new functionality. Some JSRs that could not be included in the last release, primarily because of scheduling constraints, are targeted to be included here as well. So what are the key themes for the release?
-
Support for latest Web standards such as HTML5 server-sent events, standardized binding between JSON text and Java objects, HTTP/2 support, action-based MVC, updates to Java API for WebSocket and JSON Processing.
Some features, such as HTTP/2, action-based MVC, and JSON Binding, are fairly big additions to the platform and are filed as separate JSRs. Others are relevant but can be easily consumed within other components JSRs.
-
Further simplification of the programming model by CDI alignment across the specs. Today declarative security and @Schedule can only be specified on Enterprise JavaBeans. This is targeted to be made more generically available for POJOs.
Now, would this make the EJB programming model obsolete? Only time and developers will tell. But if so, there are some unique features to EJB such as remoting, concurrency, and pooling that would need to be extracted and applied more widely to POJOs. JAX-RS has a few areas where cleanup is required such as CDI alignment, server-side async, and simpler hypermedia API. Older EJB 2-style APIs and CORBA IIOP interoperability are also targeted for pruning.
-
Infrastructure for cloud support. Some basic support for cloud infrastructure was added in Java EE 7, such as schema generation in JPA 2.1 and resource library templates in JSF 2.2. This release will extend that to add flexible configuration of applications such as multi-tenancy and simplified security. REST-based APIs for management and monitoring will allow building a custom dashboard that will be portable across different application servers.
-
Java SE 8 alignment. Java SE 8 introduced several new features such as repeating annotations, lambda expressions, the Date/Time API, type annotations, and CompletableFutures. Component JSRs will be encouraged to take advantage of these features. For example, @DataSourceDefinitions, @JMSConnectionFactoryDefinitions, @MailSessionDefinitions, @Schedules and other similar annotations can be deprecated in favor of repeating annotations. Expression Language added support for Lambda expressions on their own, primarily due to Java EE 7 and JDK 8 schedules not aligning. This support would need to be replaced with a JDK 8 standard one now. JPA can also leverage all the goodness in Date/Time API.
Here is a quick overview of features from the component JSRs filed so far:
-
-
Leverage existing Java EE technologies
-
Model should leverage CDI and Bean Validation
-
View should leverage existing view technologies like JSPs and Facelets
-
Controller might be JAX-RS based, or perhaps defined using some new technology. A technology-independent way of defining controller may also be considered.
-
Defining a new templating language is out of scope; existing languages such as Freemarker, Velocity, and others should be evaluated, and possibly define an SPI for additional ones to be integrated
-
-
-
Standard way to convert JSON into Java objects and vice versa.
-
JSON-B will leverage JSON-P and provide a conversion layer above it.
-
A default mapping algorithm will be defined for converting existing Java classes to JSON. The default mappings can be customized through the use of Java annotations and will be leveraged by the JSON-B runtime to convert Java objects to and from JSON.
-
Requirements from upper layers of JAX-RS
-
JSON-B will have a similar feel to JAXB
-
-
CDI 2.0 (JSR 365) (@cdispec, cdi-dev)
-
Split CDI into two parts: Core CDI programming model and Java EE integrations for CDI
-
Define a portable bootstrap API for CDI
-
Overhaul thread-bound request-response context model, allow the application or container to portably push the active context to CDI when it requires the use of CDI
-
Introduce modularity to CDI, CDI 2.0 Modularity Proposal
-
Define a lightweight container
-
-
Servlet 4.0 (JSR 369) (@servlet_spec, users@servlet-spec)
-
Expose support for the upcoming IETF standard HTTP/2 to users of the Servlet API
-
Request/response multiplexing
-
Stream prioritization
-
Server push
-
Upgrade from HTTP 1.1
-
-
Refresh the Servlet API with to achieve compliance with new features in
-
HTTP 1.1
-
Responding to community input
-
-
JAX-RS 2.1 (JSR 370) (users@jax-rs-spec)
-
Adding support for server-sent events
-
Improving integration with CDI
-
Exploring support for non-blocking I/O in providers (filters, interceptors, etc)
-
Evaluating ways in which declarative security can be supported either directly in this JSR or by leveraging other EE-platform JSRs
-
Making JAXB conditional on runtimes where it is available
-
Providing integration with JSON-B
-
Building upon the hypermedia API added in version 2.0
-
Investigate the reactive programming paradigm as a way to improve the JAX-RS asynchronous client API
-
Alignment with MVC JSR
-
-
JSF 2.3 (JSR 372) (@jsf_spec, users@javaserver-faces-public.java.net)
-
Ajax method invocation: Allows invoking CDI managed bean methods directly from Ajax, allowing the response to be sent using standard JSON
-
Community input: multi-field validation, @Inject FacesContext, EL performance optimizations, and cross-form Ajax clarifications
-
Better integration with Java EE 8 and Java SE 8
-
-
JMS 2.1 (JSR 368) (@jms_spec, users@jms-spec.java.net)
-
Simplifying and extending the API required to receive messages asynchronously
-
Portability of JMS providers within Java EE servers will be improved
-
Clarify “application server facilities” in chapter 11 of JMS 2.0
-
Clarify JCA resource adapter relationship
-
Improvements in JMS provider in Java EE transaction
-
Corrections and minor enhancements
-
JCache 1.0 (JSR 107) has at last gone final and so will be a candidate for inclusion in the platform. Similarly, MVC 1.0 and JSON-B 1.0 will also be considered for inclusion. Note, that the expert group decides whether this spec should be included in Java EE 8. Even though there are no apparent reasons for the EG to go otherwise, the decision still rest with them.
Anatole Tresch has shared proposals for the Configuration JSR. A strong 64% requested this JSR as per a Java EE 8 community survey. It would be a shame if it could not be included in the platform, but it seems like that is in dead in the water right now.
Survey results also showed standardized logging requested by over 70% but there does not seem to be anything happening in that area. There was also strong support for simplified security. However there are rumours about a separate JSR to address security, so let’s wait and watch.
Some other component JSRs have already gone through maintenance release and so an updated version will be included in the platform. More component JSRs should be filed in the coming days.
What’s going to happen next? The JSRs have been filed and recently were unanimously approved by the JCP executive committee. Now, expert groups will be formed and that’s when the majority of the work will start. This typically involves discussing the scope, preparing proposals, EG meetings, javadocs, API, reviews, etc. All the JSRs are following JCP 2.9, which requires one or more of early drafts, public review, proposed final draft, and final release. Of course the reference implementation and TCK go along with all of this as well.
GlassFish, even though Oracle pulled commercial support from it, is still slated for a reference implementation in Java EE 8. So initial implementation of different components will start in their respective projects, such as Weld for CDI 2, Jersey for JAX-RS, new projects created for JSON-B and MVC, and so on. But eventually they will start integration into GlassFish 5.
A tentative timeline for Java EE 8 is:
Q3 2014 Expert Group formed
Q1 2015 Early Draft
Q3 2015 Public Review
Q4 2015 Proposed Final Draft
Q3 2016 Final Release
Given that the Java EE 7 (JSR 342) original timeline was changed from Q3 2012 to Q1 2013, lets see how realistic this timeline is. Everybody in the Java community will be closely watching the specifications evolve. But just don’t sit outside and watch. Like last time, there will be Adopt-a-JSR efforts, only this time they will start happening from early on. In general, read the proposed scope of each JSR and share your comments on the mentioned alias, at least for some of them. At the least, share your thoughts here. JCP has arranged Hackergarten at JavaOne to get early feedback on Java EE 8, so make sure to check it out.
Personally, I’d love to see more openness in the specification process. Specifically, I would love to see all the Java EE 8 specifications using AsciiDoc for authoring as that truly promotes collaboration. CDI and Bean Validation already use it for spec authoring, and that allows everybody to watch the process transparently.
With JavaOne around the corner, it’ll be good to see community’s reaction on Java EE 8.
You can always find the latest status on Java EE 8 here.
About the Author
Arun Gupta is Director of Developer Advocacy at Red Hat and focuses on JBoss Middleware. As a founding member of the Java EE team at Sun Microsystems, he spread the love for technology all around the world. At Oracle, he led a cross-functional team to drive the global launch of the Java EE 7 platform through strategy, planning, and execution of content, marketing campaigns, and program. After authoring ~1400 blogs on different Java technologies, he continues to promote Red Hat technologies and products. Arun has extensive speaking experience in ~40 countries on myriad topics and is a JavaOne Rockstar. He also founded the Devoxx4Kids chapter in the USA and continues to promoting technology education amongst kids. An author of a best-selling book, an avid runner, a globe trotter, a Java Champion, JUG leader, he is easily accessible at @arungupta.