Even though this approach looks very modern and future-proof, its feasibility is certainly the biggest question. The remaining fundamental question, then, is how such a dramatic change of strategy could be developed "in the dark", without a Java expert group or even the JCP taking part in it. This is unlikely to happen in just a year - unless Oracle has already steered the available resources which were subtracted from Java EE 8 back onto this path. Java EE 8 could quickly lean toward something like Amazon's Lambda architecture. This is where the new Serverless hype comes in handy, too. Red Hat’s separate Micro-Profile will probably also shift in this direction. Detaching the API from the implementation and offering a new, simpler runtime in the cloud, is a logical step. The APIs are well known and used by many developers. Perhaps the service will soon be able to understand the Java EE APIs, just without the underlying application server. In its literature, on the Java Cloud Service Oracle already bandies about terms like managed servers and scaling. This would tie in with Gartner’s prediction that traditional application platforms are dead. Moeller’s comments, when it comes to cloud and distributed systems, suggest it could be time to wave goodbye to the application server itself and an extensive collection of reference implementations and to put on some "lightweight" Java SE.
Java EE 8 is Java SE + Cloud APIs (serverless) But in principle, the question remains as to why Oracle should wish to hand off the future of a central platform to someone else. Whether this would be a one-time exception for Java EE 8 or a complete handover for the future developments, no one knows. This is certainly nothing that could not be worked out with contracts. Oliver Gierke says that licensing reasons are a significant impediment to this scenario. Getting around this in Java EE 8 would probably require a radical change in the JCP or optionally additional contracts with the still unspecified "key partners”. Rereading the JCP Process Document reveals that Oracle reserves the final veto right for all Java platforms. What could easily be achieved by changing the specification lead on the umbrella JSR has significant legal implications. It is perhaps the least exciting variant of the future, but it is also probably the most likely.įocusing on Moeller’s second quote, about working with key partners in the Java community on a new proposal, the possibility remains that Java EE 8 will be completed without Oracle. Looking at today’s defined scope for Java EE 8 it seems as if the changes are manageable.
Java EE 7 needed 13 months from early draft to final release. In order to achieve the short development-timeframe target, less than a year remains to get this done. That would align with a specification request (JSR 366) that doesn’t even list, for example, JSR 107 (JCache) or one of the most discussed new additions – MVC 1.0. This would lead to a version 8 with only a couple of new features and minor updates rather than fundamental changes. Some statements on expert group mailing lists, for example the Java Persistence API mailing list, suggest that planning for Java EE 8 didn’t contain fundamental changes and many specifications will only produce a so-called maintenance release. But what does this all really mean? Which possible outcomes or Java EE 8 might we imagine based on Moeller’s comments? Java EE 8 as maintenance releaseĪssuming Moeller was not sure what he was saying, and the second part of the above-cited sentence contains a healthy mix of product half-knowledge, then it might be assumed that he actually meant that Oracle is still supporting and driving Java EE 8.
#Java se development kit 7 install progress stalled full
Moeller continues: "Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September."Īnd thus the Community breathes a sigh of relief and starts anticipating JavaOne.
0 kommentar(er)
