The title of this post may seem strange, but if you look a bit into Java EE's recent history, it will make sense.
Originally, Sun started and ran Java Enterprise Edition, and later Oracle took over after it acquired Sun. Specifications were driven by a Sun/Oracle-governed process. At more or less regular intervals, they made a new version of the specification available, which was implemented by the server vendors. Those vendors had to license the technology compatibility kits (TCKs) and brand from Oracle.
Let's fast-forward a bit. In 2013, Java EE 7 was released, and Oracle began work on EE8, but it did not progress quickly. Meanwhile, new technologies like Docker and Kubernetes came along and changed the way applications run. Instead of running a single fat server process on a big machine, the software is now split into smaller, independent services that run in a (usually) Docker container orchestrated by Kubernetes.
To fully take advantage of the new way of running software, changes were needed in the setup of software and projects. The term "cloud native" was born and the 12-factor methodology was created to describe these new requirements. To quote one factor:
III. Config
Store config in the environment
There was no good, uniform way to achieve this in the specification, and every developer had to do this in an ad-hoc fashion.
The Enterprise Java community saw those changes and challenges and wanted to make use of them, but Java EE 7 did not take care of it, and a Java EE 8 release was nowhere in sight. To the community, it looked like Oracle lost interest in Java EE, and reports about evangelists being laid off and developers being moved to other software projects inside Oracle did not help counter that impression.
To overcome this restriction and to adapt Java EE to the new world, a group of interested parties, including the London Java Community, Red Hat, Payara, IBM, SouJava, Tomitribe, and others, started the MicroProfile effort in 2016. MicroProfile's purpose was to develop the missing cloud-native features to potentially be included in a future Java EE version.
And still, no Java EE 8 was in sight.
Moving to Jakarta
MicroProfile moved to the Eclipse Foundation and made several releases, one just before the JavaOne conference in 2017, when suddenly Java EE 8 was released—but without really addressing the cloud-native requirements.
In September 2017, after JavaOne and just before EclipseCon Europe, Oracle announced it would donate Java EE to the Eclipse Foundation. This was a revolutionary move, as Oracle included not only the specifications, but also the specification process and the formerly secret TCKs.
Eclipse formed the Jakarta EE working group, and Oracle started to move the code over to the Eclipse Foundation's Git repositories, a process that is still happening.
In parallel, a project management committee (PMC) was formed to guide the process. In late February 2018, the committee announced a new brand name: EE4J. (For those of you who recall Jakarta as a set of Java projects at the Apache Foundation: Yes, this is not a clash, rather a friendly revival, as PMC member and Tomitribe founder David Blevins described it.
The next steps were to set up the various committees and, most important for the geeks in us, create a logo. Finding a logo in an open source way without violating trademarks was not easy and also involved some kerfuffle through the process—but nothing that couldn't be solved.
Finally, on April 24th, the new Jakarta EE logo and website were revealed.
Jakarta EE is now attracting new members that no one suspected would be interested in this ecosystem, like Microsoft and even Pivotal (Spring).
If you wonder about the naming, particularly EE4J vs. Jakarta EE, the simple answer is: "always use Jakarta EE." PMC lead Ivar Grimstad summarized the controversy well.
What's next?
One of Jakarta EE's first efforts (which has been going on since Oracle announced its intentions to submit Java EE to Eclipse) is to be able to fully build a Java EE 8-compatible server from the Jakarta EE sources. After this goal is achieved, development of new features can go ahead at full steam.
Mike Milinkovich, director of the Eclipse Foundation, shared his perspective in an interview on Jaxenter.com (listen between minutes 2:30 and 11).
What about MicroProfile? The MicroProfile and Jakarta EE communities already have a large overlap, so it is expected that after Jakarta EE 8 the communities will decide how they will work together. I think MicroProfile will work as some sort of incubator for Jakarta EE. This would allow new features to be developed and refined quickly inside MicroProfile. Later they would be promoted to a Jakarta EE-level spec and stay more stable over a long(er) period of time.
2 Comments