Work on Java EE 8 is well on its way, and there have been a lot of developments this year – so now seems like a great time for a roundup! Without further ado, let’s dive right in…starting with a look at Java EE 7.
Java EE 7 revolved around three important themes:
- HTML 5 alignment – Java API for WebSocket (JSR 356), JSON Processing (JSR 353), JAX-RS 2.0 (JSR 339)
- Developer productivity – CDI 1.x , JMS 2.0 (JSR 343)
- Meeting enterprise demands – Concurrency Utilities (JSR 236), Batch Application API (JSR 352)
Major enhancements to other specifications included:
- EJB 3.2
- JMS 2.0
- Servlet 3.1
- JPA 2.1
- JSF 2.2
- Bean Validation 1.1
- Interceptors 1.2
Note: The Java APIs for WebSocket (JSR 356), JSON Processing (JSR 353), Concurrency Utilities (JSR 236) and Batch Application API (JSR 352) were new specifications added in Java EE 7.
Certified Application Servers (Full Java EE Platform support)
Note: Oracle Weblogic 12.1.3 has support for the following Java EE 7 specifications *only* – JAX-RS 2.0, WebSocket 1.0, and JSON-P 1.0.
How is Java EE 7 doing in the real world, a.k.a production environments?
Take a look at this slideshare by Arun Gupta for more insights on this. I’m sure there are bigger and better deployments to follow.
Continue supporting and contributing to Java EE 7!
Visit Adopt-a-JSR for Java EE and definitely take a look at this JavaOne 2014 talk if you want to understand the overall JCP processes and specific details with regards to Adopt-a-JSR for Java EE 7 and Java EE 8.
And on to Java EE 8…
Java EE 8, a.k.a JSR 366, is the next version of the Java Enterprise Edition Platform.
Major themes and driving factors:
- Support for Java SE 8 – enhance APIs to use the latest capabilities of Java SE 8.
- Keeping pace with evolving HTML 5 standards – Enhance Web Tier technologies (WebSocket, JSONP etc) as per latest standards.
- Alignment with HTTP 2.0 – Servlet 4.0 to bundle support for HTTP 2.0 standards.
- Tighter integration with CDI – Extend, improve and standardize CDI support to other parts of the specification (JAX-RS, WebSocket, etc.).
- Improve capabilities for cloud based applications – Improving application security, REST based management APIs, multi-tenant support, etc.
- MVC 1.0 (JSR 371)
- JSON-B 1.0 (JSR 367)
- Java EE Security 1.0 (JSR 375)
- JCache (JSR 107)
The specifications which are on target for an update to date are as follows:
- Servlet 4.0
- CDI 2.0
- JAX-RS 2.1
- JSF 2.3
- JMS 2.1
- JSON-P 1.1
This post will deal with these new specs.
As the name suggests, the goal is to define a standard *Model-View-Controller* API for Java EE. For long-time Java EE developers, experts and followers, the first question might be, *why another MVC in addition to JSF*? Well, I would highly recommend this write-up by Ed Burns (JSF Spec Lead at Oracle) which will help clear any doubts which you might have.
- JSF is not going anywhere. Rest assured! In fact JSF 2.3 will be a part of Java EE 8 (More on this in a future post).
- MVC 1.0 is being looked at from a perspective of an action based MVC framework as opposed to a component based one (like JSF) – so, basically, they are quite different from each other
The Java EE 8 Community Survey (check page 3 of the PDF) results were highly in favour of another MVC framework alongside JSF.
– Make use of existing Java EE technologies.
– Model part might use JPA (2-way binding b/w model and DB), CDI (for obvious reasons) as well as Bean Validation.
– The View part might reuse existing view technologies like JSP.
– The Controller portion has a few options – maybe JAX-RS or a new spec altogether ?
Note: Jersey, the JAX-RS reference implementation, already provides support for MVC via an extension – this is of course proprietary, and not a part of the JAX-RS standard as of now. I would recommend peeking into this.
JSON-B (JSR 367)
If you have worked with or used the JAXB API, JSON-B will sound familiar. It is the JSON counterpart of JAXB and its goal is to define an API which will enable developers to bind JSON data to a Java domain model (class) with help of annotations as well as convert (marshal/un-marshal) these POJOs to/from JSON at run time. In the absence of a standard/pure JSON API, we use 3rd party libraries and frameworks which basically interpret the JAXB annotations on POJOs in a different way to produce JSON rather than XML. This of course comes with few drawbacks and caveats and JSON-B will look to solve this issue by providing a standard and portable API to make it easier for us to work with JSON data and corresponding Java domain objects.
– Will leverage existing JSON-P (JSON Processing introduced in Java EE 7) API i.e. build an API layer on top of it.
– Unlike few other specs (which are targeted towards Java SE 8 and Java EE 8), this will work on Java SE 7 as well as Java EE 7.
– To foster rapid and easy adoption, the general usage pattern/nomenclature of the API will be similar to JAXB.
````JSONContext jsCtx = JSONContext.getInstance(Speaker.class);
Unmarshaller jsonUnmarshaller = jsCtx.createUnmarshaller();
Speaker speaker = (Speaker) jsonUnmarshaller.unmarshal(new File("speaker-detail.json"));````
Java EE Security 1.0 (JSR 375)
The Java EE Security specification aims at (stating the obvious a little here) providing a simplified Security API which can enable Java EE applications manage their own Security parameters in a unique yet portable manner. Like JSON-B and MVC, this JSR is also a result of strong community feedback. See pages 12,13 of the Java EE 8 Community Survey result. Another key motivation behind this JSR is to help cloud based Java EE application deployments where a standard and portable way of defining Security aspects is an extremely desirable feature.
Note: If you have worked with or heard of PicketLink, this API might sound similar.
- User and Role Management – Both these areas are not yet standardized by Java EE
– The idea is to provide an API to interact with User and Role repositories (RDBMS, LDAP compliant directory servers etc) and execute user and role related operations such as User CRUD, Role-User relationship CRUD.
- Authentication – Providing the ability to an repository for a particular Java EE application (based on the aforementioned User and Role management APIs).
– Async API for authentication via HttpServletRequest.
– Enable different Servlets within a singe Java EE application with the help of different authentication methods e.g. you can configure both Form based and Basic authentication mechanisms for different Servlets belonging to a single web app.
- Authorization- Introduce fine grained criteria (rules based on application requirements) for method level access in addition to already existing role based access control.
- Password Aliasing – Introduce the concept of a *Password Alias* (based on standard syntax) which would need to be *resolved* to the actual password value which itself would be stored in a secure, self contained archive along with the application. Overall, the goal is to foster secure and standardized means of dealing with password storage and retrieval in Java EE applications.
JCache (JSR 107)
JSR 107 provides a standard and portable API for use within applications which need in-memory caching of Java objects. The good thing is that work on this JSR is already complete. It missed the bus as far as Java EE 7 is concerned, but will most probably be integrated into the Java EE stack starting with Java EE 8.
I will write about updated specifications in Java EE 8 in my future posts. For the latest and greatest on Java EE, stay tuned to the The Aquarium!
And for even more Java EE goodness, check out this Java EE webinar series, led by Arun Gupta:
- Java EE Webcast: Being Continuous
- Java EE Webcast: What jOOQ Brings to Java EE
- Java EE Webcast: Building Modular Applications Using OSGi