BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Java EE 8 Delayed Until End of 2017, Oracle Announces at JavaOne

Java EE 8 Delayed Until End of 2017, Oracle Announces at JavaOne

This item in japanese

Lire ce contenu en français

Bookmarks

After weeks of speculation, Anil Gaur, Oracle Group Vice President with responsibility for Java EE and WebLogic Server, has unveiled Oracle’s proposed roadmap for Java EE today at JavaOne. The plan is to release Java EE 8 by the end of 2017 with basic microservice and cloud capabilities, and then to release Java EE 9 one year later with further features.

Consistent with his appearance at the JCP Executive Committee a month ago, as well as during an interview with Thomas Kurian, president of product development at Oracle, Gaur’s presentation at the Java Keynote at JavaOne revolved around three basic principles: Java EE as the place to standardise innovation in the Enterprise Java space, changes that Oracle may have for Java EE needing to be executed through and with the community, and Oracle believing in and wanting to be part of the future of Java EE.

Regarding new features, Gaur indicated that while new application development styles like reactive programming or containerisation can provide great benefits, they can also prove challenging for the average developer. For this reason, he emphasised that Oracle’s strategy for Java EE is to expand its functionality to standardise these practices, saving the developer from having to evaluate different competing solutions out there. More precisely, Gaur proposed that Java EE 8 is extended with enhanced Security (in the form of secret management and support for OAuth and/or OpenID), an API for self-contained configuration, and also another one for health checks (potentially supporting application monitoring), with the aim of having all this ready by the end of 2017. He then extended to a proposed architecture, potentially available with Java EE 9 at the end of 2018, that would include other features like Eventual Consistency or Key-Value storage, to name a couple.

Proposed Platform Architecture for Java EE
Anil Gaur presenting the proposed architecture for Java EE.

Despite the relevance of the announcement, Gaur highlighted that Oracle is determined to work with the community to effect all of these changes, beginning with a public survey to understand how people create, configure, manage and package their applications. Finally, to showcase how relevant Java EE still is to the industry, Gaur showed a number of active Open Source projects that are based on Java EE (including the MicroProfile), and invited eight different organisations, in fields ranging from research (CERN) to finance (Nykredit) to speak about how they currently use Java EE and how they would like to use it in the future.

Given the past pace of development, it may seem a bit unlikely that Oracle will manage to release two new versions of Java EE within the next 30 months, however, the message seems to be that Java EE is going to receive much more attention from now on. Once the JSRs for all the new features are created and work on them begins, we will be able to evaluate the degree to which these plans will materialise.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Let ASP.NET MVC and Spring MVC Bury This Monster!

    by Timothy Liu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Let ASP.NET MVC and Spring MVC Bury This Monster! Now is the good time for Java EE to die.

  • Re: Let ASP.NET MVC and Spring MVC Bury This Monster!

    by Ryan McDonough,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agreed. I've been using SpringBoot for the past 2 years and it ticks all of the proposed checkboxes. After having to work on a .NET project, a modern OWIN/MVC 5 stack ticks similar check boxes. JavaEE 8 will be too little to late.

  • Re: Let ASP.NET MVC and Spring MVC Bury This Monster!

    by William Smith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Certainly right now Spring Boot and Cloud Foundry is the best way of building cloud apps in Java I don’t really see a role for ASP.NET but whatever floats your boat.

    But given that the foundations of Spring rest quite heavily on Java EE Java EE still matters.

    I also think there is a role for Java EE in cloud - specifically around portability and lock-in. The lack of portability between different cloud providers seems to be a significant area of concern - well explored here:
    www.infoq.com/minibooks/emag-cloud-portability

    As a standard Java EE could provide this which would be a good thing.

  • Re: Let ASP.NET MVC and Spring MVC Bury This Monster!

    by Ryan McDonough,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Springs reliance on JavaEE is actually quite limited depending on how you use it. Yes, if you deploy to a JavaEE app server, Spring relies on Java EE. But if I'm using SpringBoot, JavaEE reliance is greatly reduced. At this point, I'm relying mostly on servlets and maybe a JDBC datasource. But it's very easy to not use any of these. For example, I can use Ratpack.io and Cassandra and not touch any JavaEE API. Since SpringBoot has been released, I have to do things like a JNDI lookup, use JMS, etc. Everything is self-executable JAR as opposed to a WAR deployment.

    As for Cloud interop: JavaEE cannot provide a valuable solution to this problem. A large portion of Cloud vendor lock-in is a configuration management problem, not a Java API problem. If Oracle is seeking to address this aspect, they're barking up the wrong tree. Cloud deployment is a language-agnostic problem and I'd really like to not see Oracle present something Java-specific. Containers are just fine and my Node.js apps are now deployed the same way as our Java apps: in Docker containers.

    The bigger problem is that Oracle is going about this in an old school manner and lumping multiple releases in a big bang release. For Java itself, that's fine. But JavaEE is collection of different APIs that all have their own lifecycle. The JavaEE releases only benefit app server vendors. As an end user, I cherry pick which ones I use. I haven't relied on a JavaEE container for past 6 years and I'm not waiting for one either. Release the underlying APIs when they are ready as opposed to waiting for the big bang release.

  • Re: Let ASP.NET MVC and Spring MVC Bury This Monster!

    by Will Hartung,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    They should have just done a new initiative outside of JEE. I agree that Cloud != Enterprise, particularly in JEEs view of "Enterprise". JEE is about creation and integration of "enterprise" systems. While there's a deployment aspect of it, the bulk of functionality within JEE is orthogonal to deployment.

    We still have not seen a new "spec" for "JEE 8", but I still believe they ditched pretty much the entirety of what was discussed before, bolted on "Java Cloud stuff" under the JEE8 aegis and called it a day -- thinking that somehow they're actually moving the community forward.

  • Re: Let ASP.NET MVC and Spring MVC Bury This Monster!

    by Michael McCutcheon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agreed. In the age of Spring Boot, Vert.x, Play Framework, RatPack, etc. Java EE has become the dinosaur tech for big, bloated app servers. There is no use for this any more. It's time has come and gone.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT