What’s up with Java EE 8 ?

UpdatePart 2 of this post is available here. It talks about the updated specifications in Java EE 8

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

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

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


  • 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

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 !


About Abhishek

Loves Go, NoSQL DBs and messaging systems
This entry was posted in Java, Java EE and tagged , , , , , , , . Bookmark the permalink.

10 Responses to What’s up with Java EE 8 ?

  1. Hi Abhi,
    Good info on upcoming JavaEE8.
    I am interested to deep dive into JavaEE MVC implementation from beginning!!
    If I want to keep track of work being done on new JSRs like MVC or Security what is the best way?
    Can i get any reference implementation links in JSR page itself or should i look into source code of Glassfish/Wildfly etc?


    • Abhishek says:

      Hey Siva – thanks for reading!

      To answer your questions

      1. if you want to keep track of progress of work on the individual JSRs, the best way is to join individual mailing lists.
        > Just visit the JSR page e.g. for MVC, go to https://jcp.org/en/jsr/detail?id=371
        > You would see a link to the Public Project page on the JSR page e.g. for MVC, its https://java.net/projects/mvc-spec/pages/Home
        > On the Public Project page, you would see an option to access the Mailing list (top left) e.g. https://java.net/projects/mvc-spec/lists

      That’s it !

      1. For list of Reference Implementations, I would ask you to look at the corresponding vendor page to get a comprehensive list of RIs which they bundle. As far as individual JSRs are concerned, their JSR as well as Public Project Page list out the RI as well as links to the RI source repo

      Hope this helps!


  2. Abhishek says:

    By ‘vendors’, I meant the application server vendors like GlassFish, WildFly etc. I would recommend reading this excellent post (http://arjan-tijms.omnifaces.org/2014/05/implementation-components-used-by.html) by Arjan Tjims on the Java EE implementation landscape and how different Java EE vendors package various RIs as a part of their Java EE platform implementation


  3. Pingback: What’s up with Java EE 8 ? (part 2) | Object Oriented . .

  4. Pingback: Ausblick auf Java EE 8 (JSR 399)

  5. Pingback: JAX-RS and JSON-P integration | Thinking in Java (at least trying to!)

  6. Albert says:

    The new security model has also focus on portability, but how does it differs from JASPI(C)? This was also meant for portability if i’m not mistaken.


    • Abhishek says:

      You are right Albert 🙂 JASPIC is supposed to be portable (there are some rough edges in its implementations though). In short, JASPIC defines how the client and server interact during the authentication process. The actual authentication itself is something which it does not define e.g. how to fetch the credentials from a LDAP/DB etc. Java EE 8 Security API (JSR 375) aims to standardize this. One of the features is to provide a standard API for accessing identity stores. All in all, JSR 375 is supposed to work in tandem with JASPIC

      This answer might be far from perfect! I also encourage you to raise this question on the JSR 375 mailing list – https://java.net/projects/javaee-security-spec/lists

      Some more info here (right from the experts!) – https://twitter.com/OmniFaces/status/685073163911323648


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s