Exclusive: Oracle to reboot Java EE for the cloud
Rumored to have put the project on the back burner, Oracle has weathered a storm of complaints over its stewardship of enterprise Java, with two separate organizations considering plans to move Java EE forward without Oracle. Rather than let Java EE wither, Oracle is instead looking to reboot the platform to better accommodate where enterprises are headed, particularly to the cloud, said a high-ranking Oracle official in response to recent criticism.
In an exclusive interview this week, Oracle’s Thomas Kurian, president of product development, emphasized ambitious intentions to modernize the server-side platform, for which Oracle is gathering feedback now.
“A lot of our goals with Java EE 8 have come from a very simple premise: Where does the next generation of applications run” Kurian said. Oracle wants Java developers to be “viable in the new world,” given the continued evolution of computing toward cloud deployments, Kurian added.
This modernizing agenda comes amid allegations of Oracle’s disinterest in Java EE, specifically the planned Version 8 release, which is slated for arrival next year but could be delayed. The situation has prompted both Java EE Guardians and MicroProfile.io to consider developing Java EE improvements on their own sans Oracle.
If Oracle’s proposed plans for modernizing the platform go forward, as outlined by Kurian, Java EE Version 8 may provide much-needed benefits for enterprise organizations targeting containers and the cloud.
While Oracle plans to publicly introduce its updated Java EE strategy at the JavaOne conference in San Francisco in late September, Kurian offered several significant details about where Java EE is headed.
“Oracle has a very clear plan for Java EE 8,” Kurian said. This plan, Kurian explained, will move Java EE into modern computing realms, specifically the cloud.
Java EE was written many years ago to help enterprises build websites and applications on top of application servers, Kurian said. Applications have since shifted from that application-server-based model to a cloud-based model, a very different paradigm with distinct requirements for composing applications for reliability and scale. This shift in how infrastructure runs underneath enterprise applications requires a significant evolution of Java EE 8, he said.
Within cloud-based environments, infrastructure no longer relies on application servers running on dedicated hardware. Moreover, an enormous volume of transactions must be handled, requiring a different model for state and transaction management than what has been offered in Java EE for scaling applications, Kurian said. Meanwhile, container technologies such as Docker have emerged, with requirements for externalizing configuration management, deployment of applications, and packaging. Oracle wants to make accommodations for these paradigm changes.
Oracle plans to fit Java EE 8 with capabilities for persisting data in a key-value store, based on NoSQL stores, and a transaction model for eventual consistency and relaxed transactions. On the whole, Oracle's improvements would help Java EE developers evolve their skill sets to leverage technology shifts such as these, Kurian said.
The next iteration of Java EE will also include improvements aimed at multitenancy in cloud environments. Multitenancy enables applications from multiple companies or departments to be hosted on the same shared infrastructure. By providing greater density in packing applications on a common infrastructure, multitenancy reduces the cost of infrastructure, Kurian said. “Today, Java EE does not have a formalized model for app developers on how an app server can provide multitenancy.”
Java EE will likely also receive security improvements, Kurian said. The existing specification primarily deals with authentication and authorization. But on public clouds and in the enterprise, new authentication models are emerging, such as OAuth and OpenID Connect. “Today, there is no formalized model within Java EE 8 on how you receive these open standard token formats for authentication [of] users, propagating identity and providing better interoperability between applications from a security point of view.”
Java EE’s current configuration model, covering application servers and application deployments on top of them, is getting old, Kurian explained. That model can be improved via technologies such as Docker and other container technologies, which offer simplicity and work well with cloud deployments. Containers would make use of immutable configuration, externalizing the process from within application servers. Configuration changes would then be made via a configuration service.
Also on the drawing board is a better model for reactive programming. “Java EE does not have a very elegant model for how you do a reactive style of programming,” Kurian said. For example, Java EE lacks a single event model across the stack, instead supporting multiple event frameworks. Reactive programming is needed for building large-scale distributed systems, which are built asynchronously, are loosely coupled, and are event-based, he said.
Based on Oracle’s new plan, Java EE 8 would have stronger support for HTTP/2 than originally intended, said Kurian. “The current proposal in our view doesn’t go all the way to what Java EE 8 should do with supporting async communications over HTTP/2.”
Oracle also envisions that new applications will be written in a microservices design, with applications designed as modular services. “We believe that’s another element of what should be in Java EE longer term,” Kurian said. Asked whether Oracle’s microservices intentions would negate the work considered by MicroProfile.io, Kurian said Oracle would like to see convergence around a single specification for using microservices within Java EE. MicroProfile.io, which features involvement from IBM and Red Hat, is preparing an enterprise Java microservices platform that includes JAX-RS, CDI, and JSON-P.
Improvements previously expected in Java EE have covered areas such as HTML5 and HTTP 2.0. “We’re not scrapping that plan. What we’re pointing out is by themselves those JSRs [Java Specification Requests] are not sufficient to help application developers build cloud-scale apps using Java EE,” Kurian says.
What Kurian could not say is whether the planned improvements to Java EE would push back the release of Version 8. The intent is to discuss the plan with partners and the community as a whole first. Oracle does not want to rush out Java EE 8. More JSRs are expected to be filed in accordance with Oracle’s latest intentions for the next version.
At Java EE Guardians, leader Reza Rahman, a former Java EE evangelist at Oracle, this week expressed hope that Oracle would move forward with the platform. “We also hope that decisions with regard to Java EE 8 will be made in the open through the JCP [Java Community Process] with direct community input. So far we have seen no change in the inactivity in the JCP."
Kurian emphasized a quest to keep developers happy.
“Listen, at the end of the day,” he said, “we believe that if we’re doing the right thing for the developer community, we believe the developer community will rally around it.”