Thoughts on the Java EE 8 Update
Thoughts on the Java EE 8 Update
After long being accused of abandoning Java EE, Oracle has announced a significant roadmap for the product.
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
At the keynote of this JavaOne, Oracle presented a long-awaited reaction to the progress of Java EE in the 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 the allegedly 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 slightly reorient for the new demands 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, Configuration 2.0, and JMS 2.1. These changes are justified in that MVC and JMS are “no longer very relevant in the cloud” and Configuration wouldn’t have been widely used in the past, respectively. The plans also don’t include JCache to be in a future version of the platform umbrella.
First of all, it is very good to see a reaction to the Java EE progress from Oracle's side. The additions and updates 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 don't make sense to me. The latest developer surveys showed a great demand and interest in (finally) adding a standardized, action-based MVC, the JSR 371 expert group has been quite active, and the specification is very much progress. In my client projects, there was also a constant requirement for this approach, which always had to be tackled with homegrown 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, needed to still have server-centric rendered pages.
Another JSR that 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 availability requirements — although the JSR could need an update that finally includes standardizations for distributed caching — mechanisms that 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 that is being 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. By the way, 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 the container including it — runs.
The requirements that force developers to slice up monolithic applications into distributed ones (buzzword: microservices) ,such as high availability, 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 all, really good news, and the rest can hopefully be fixed with engagement from the community and other vendors.
We can look into the near future of Java EE with curiosity and high expectations. Even if we are not fully convinced how the changes and roadmaps will work out from Oracle'a side, let’s be optimistic and hope for the best.
Please do me a favor 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 developer side — in both "EE politics" and technical terms.
What do you think? Feedback is highly appreciated.
Published at DZone with permission of Sebastian Daschner , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.