Jakarta EE 9 – signs point to a big bang
Jakarta EE 8 is released and the Enterprise Edition of Java has finally moved to the Eclipse Foundation. After slowing down long enough for a few deep breaths, the time has come to start discussing what comes next for the project. Bill Shannon, Architect at Oracle, has presented a first draft for Jakarta EE 9, which is now the subject of intense discussion.
Considering the last two to three years of the Enterprise Edition of Java, Oracle’s love for Java EE could well be brought into question. But anyone who thinks that Oracle does not show any sense of responsibility with regard to the Java version will – once again – be proven wrong. None other than Oracle Architect Bill Shannon has presented a proposal for the first “real” release of Jakarta EE (Jakarta EE 9).
Jakarta EE 9 will be the first “feature release” under the umbrella of the Eclipse Foundation, but actually the second release. Version 8 of Jakarta EE was released in a version identical to Java EE 8 and can be seen as the final milestone in the move from Oracle to the Eclipse Foundation.
Jakarta EE 9 – Oracle’s proposal
Bill Shannon’s proposed plan for Jakarta EE 9 should not be taken as an official Oracle plan. It’s more a coincidence that a dedicated community member is part of Oracle’s Java EE community and – of course – also talked to his colleagues about the possible next step for the Enterprise Java project. These considerations and thoughts led to a statement from Oracle, which was finally revised after some comments and accepted in its current form as an official proposal for and by the community as a basis for discussion.
The first part of the Jakarta EE 9 plan concerns the removal of some specifications from Jakarta EE 9:
- Jakarta XML Registries
- Jakarta XML RPC
- Jakarta Deployment
- Jakarta Management
- Jakarta Enterprise Bean entity beans
- Jakarta Enterprise Bean interoperability
- Jakarta Enterprise Bean 2.x and 1.x client view
- Jakarta Enterprise Web Services
These will still be available at the Eclipse Foundation, but will not be updated. Of course, it should still be possible for the implementation projects to run service updates; after all the specs still have some users, but they should not be defined by the official platform specification. Meanwhile, Payara’s Steve Millidge suggests that Jakarta Management be made available as an option and expanded later.
Additionally, there are some APIs that are closely related to Java SE 8 that should not be implemented:
- Jakarta XML Web Services
- Jakarta SOAP Attachments
- Jakarta Web Service Metadata
- CORBA and RMI-IIOP
Other than these, Bill Shannon proposes to implement Jakarta XML Binding and Jakarta Activation in the upcoming version of the Enterprise Edition.
The Big Bang
Since Oracle made it clear that the namespace
javax.* for Jakarta EE was only available under the status quo of the specifications, it was clear that the packages would have to be renamed. However, it is unclear to date whether to move only the specs that will really be changed to the new namespace, pursuing a gradual approach, or whether it’s better to move all specifications immediately and at the same time.
The latter has entered the discussion as a so-called big bang approach and seems to have conquered the hearts of most developers and members of the community. Bill Shannon’s proposal is to move all specs (remaining after the cleanup) directly to the
jakarta.* namespace. The advantage: after a one-time effort and a one-time break in backwards compatibility, Jakarta EE’s further development can begin without having to re-examine the namespace question with every release.
The question about backward compatibility of existing projects should not be part of the Jakarta EE specification. Instead, the products based on Java EE or Jakarta EE should take care of this themselves. It is also possible that a separate open source project will be set up for this purpose.
Java SE, TCKs, microservices & containers
Logically, Jakarta EE 9 should also support Java SE. The minimum version is the latest long term release, Java 11. Furthermore, the Java modules should be considered, and rules and guidelines for specs that define modules should be developed. The Jakarta-EE-9 platform itself should not be modularized, but microservices should be better supported – this also applies to use without containers.
One wish that will entail a lot of work is the division of the TCK project. The aim of this idea is to enable all projects of the Jakarta EE platform to manage their own TCK. However, this is not being considered for Jakarta EE 9. On the one hand because of the workload mentioned above and on the other hand because it has to be ensured that such a change does not make testing Jakarta EE products more difficult.
MicroProfile + Jakarta EE = tomorrow’s Enterprise Java?
It’s been a while now since we published our Understanding Jakarta EE series. At that time, most people answered “no” to the question of whether MicroProfile should be transferred to the Jakarta EE project. According to the majority of participants, MicroProfile should remain an independent project in which innovative ideas and concepts can be tested. A small incubator, so to speak, for the greater good of Jakarta EE.
Bill Shannon’s proposal now strikes a different note: MicroProfile APIs are to be implemented in the Jakarta EE platform, the work of the project will be placed under the umbrella of the Jakarta EE Specification Process. However, this will not be implemented for Jakarta EE 9. This will not be an easy path if it is followed, so more time will be allowed for it.
Outlook on Jakarta EE 9 and beyond
As can be seen in Bill Shannon’s proposal as well as in Red Hat’s and Payara’s responses, the existing APIs and Specs will not be revised. The reason for this is the namespace problem: if you are already moving, then you should not rework the assets you want to move – there will be time for that later.
So the signs point to a “Big Bang” and the release date has also been announced already. The goal was to finish Jakarta EE 9 at most 12 months after Jakarta EE 8. This would mean that a version of Jakarta EE could be expected in autumn 2020, which could serve as a basis for the further development of the platform and the individual specifications – that sounds positive at first.
On the other hand, 12 months is also a long time and we will see how the landscape develops in the coming weeks. The work to make Jakarta EE the definitive place for cloud-native Java will certainly not come to an end.
Bill Shannon’s current proposal, as well as the entire discussion about it, can be found on the mailing list jakartaee-platform-dev, which is freely accessible to anyone interested. If you want to participate, you can simply register there.