Work on Java EE 8 is well on it’s way. Time to catch up! Dive in without further ado…
Don’t forget Java EE 7 just yet…..
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
- EJB 3.2
- JMS 2.0
- Servlet 3.1
- JPA 2.1
- JSF 2.2
- Bean Validation 1.1
- Interceptors 1.2
Note: Java API 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, 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 (I’m sure you’ll have access to the actual JavaOne talk pretty soon). 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 w.r.t Adopt-a-JSR for Java EE 7 and Java EE 8
JavaEE7.next() = JavaEE8 !
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
New specifications
- MVC 1.0 (JSR 371)
- JSON-B 1.0 (JSR 367)
- Java EE Security 1.0 (JSR 375)
- JCache (JSR 107)
Updated specifications
The specifications which are on target for an update are as follows
- Servlet 4.0
- CDI 2.0
- JAX-RS 2.1
- JSF 2.3
- JMS 2.1
- JSON-P 1.1
- …. more to follow
This post will deal with the new specs (announced up until now)
MVC 1.0
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.
Take away points from the above post
- 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 favor of another MVC framework alongside JSF.
Salient features
- 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
Quick links
- Official JCP page
- Reference Implementation – Ozark
- Latest talk at JavaOne 2014
JSON-B (JSR 367)
If you have worked with or used the JAXB API, JSON-B will 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 + 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.
Salient features
- 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"));
Quick links
- Official JCP page
- Reference Implementation – EclipseLink
- Latest talk at JavaOne 2014
Java EE Security 1.0 (JSR 375)
The Java EE Security specification aims at providing a simplified Security API (duh!) 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
Salient features
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.
Quick links
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.
Quick links
- Official JCP page
- The specification document
- Reference Implementation
- List of compatible implementations
- Latest talk at JavaOne 2014
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 none other than The Aquarium !
| Reference: | What’s up with Java EE 8 ? from our JCG partner Abhishek Gupta at the Object Oriented.. blog. |
