sebastiandaschner blog

At the keynote of this JavaOne Oracle presented a long-awaited reaction to the progress of Java EE in form of a suprisingly extensive update to the future roadmap.

Java EE roadmap update

Anil Gaul presented the updates to the overall plan for EE 8 and 9 in his keynote showing the proposed changes to the overall scope and target of Java EE in general and changes to the JSRs in particular. The changes are justified by alleged demanding changes in the days of cloud and microservices.

Linda Demichiel also presented the updates to the Java EE roadmap in greater detail in her conference session.

The plans include the (quite agressive) roadmap update for Java EE 8 to be finished in 2017 and version 9 to be finished in 2018. The even bigger news however is the change in the target of Java EE and the additions and removals of JSRs to the platform.

In order to meet the new requirements Oracle wants to add two new JSRs, namely “Configuration” and “Health Check” to the EE 8 umbrella, which would aim to deliver demands for sophisticated, external configuration of applications and health monitoring in a standardized way, respectively.

The existing JSRs would slighly reorient for the new demands as well in terms of resilience and reactiveness. For the longer term the list of updates would also include eventual consistency, multi-tenancy and more support for security standards.

However, Oracle also plans to remove specifications for the platform, namely MVC, Management 2.0 and JMS 2.1. These changes are justified that MVC and JMS are “not longer very relevant in the cloud” and Management wouldn’t have widely used in the past, respectively. The plans also don’t include JCache to be in a future version of the platform umbrella.

Thoughts

First of all, it is very positive to see a reaction to the Java EE progress from Oracle side. The additions and update to the platform also seem very reasonable to me, especially because of the demands for resilience, reactiveness, eventual consistency, health checks and configuration. Quite a few open source contributions have emerged, for example Deltaspike, Adam Bien’s Breakr or Porcupine projects, and vendor-specific functionalities such as reactive support in Jersey. I highly welcome features like these to be added to the platform.

Conversely, the removal of MVC and the justification thereof doesn’t make sense to me. The latest developer surveys showed a great demand and interest in (finally) adding a standarized action based MVC, the JSR 371 expert group has been quite active and the specification is very advanced in the progress. In my client projects there was also a constant requirement for this approach which for now always had to be tackeled with home-grown or third party solutions. Although client-centric JS frameworks that communicate with backends via REST and JSON are quite popular it is and will be indeed needed to still have server-centric rendered pages.

Another JSR which should be included in EE 8 is JCache. The need for caching functionality in modern enterprise systems is still relevant — especially when dealing with high available requirements — although the JSR could need an update which finally includes standardizations for distributed caching — mechanisms which are currently only included in vendor-specific ways.

In my opinion Oracle focuses way to much on the cloud. Though deploying applications in the cloud is indeed an approach which is chosen by an increasing number of developers and companies it is at the end of the day just another way of running and shipping applications. Btw: In my blog post about “Lightweight Java EE” I stated why I (still) consider application servers and thin deployment artifacts to be a very reasonable approach for enterprise applications. For this approach it actually doesn’t matter that much where the application server — or container including the same — runs.

The requirements which force developers to slice up monolithic applications into distributed ones (buzzword: microservices) such as high availablitiy, scalability or structures of organizations influence the system architecture and programming models much more. Therefore: Being ready for deployments into various kind of runtimes is a good thing, but it shouldn’t form the one and only orientation.

What should also be improved for the future is the communication to the community from Oracle side. All these changes have been anounced without any prior notification — neither to the mailing list nor to the expert groups. Maybe Oracle wanted to act mysterious and finally reveal actual news at a JavaOne conference again :-)

Anyway, the Java EE updates are in total really good news and the rest can hopefully fixed with engagement from the community and other vendors.

What’s next

We can look into the near future of Java EE with curiosity and high expectations. Even if we are not fully convinced yet how the changes and roadmaps will work out from Oracle side, let’s be optimistic and hope for the best.

Please do me a favour and participate in the process and discussions. You can start by filling out the Glassfish survey. Commenting on the JSR mailing lists is also highly suggested and appreciated — even and especially for non JCP or non EG members. Everybody profits from direct feedback from developers side in both "EE politics" and technical terms.

What do you think? Feedback is highly appreciated.