Jakarta EE 8: A critical examination of the first Java EE successor

However, the journey towards this destination was a very difficult one. A glance at the time passed will show this explicitly. After all, almost two years have passed already since Oracle had announced that they would transfer Java EE to the Eclipse Foundation. Back then, this was good news of course, because Oracle had intermediately suspended the work on Java EE and therefore the assumption that Java EE could come to an end seemed quite reasonable. The announcement of further development under the roof of the open source organization was thus, of course, extremely well received.

However, the community might have been a little bit too optimistic at that point in time. Many had hoped, that the work on Java EE would resume soon after the transfer and that they could expect new releases in the near future. This hope seemed to dwindle though when it became clear that the transfer to the Eclipse Foundation would be an utterly complex and time-consuming process. Especially the endless discussions about trademarks and name rights were quite tedious. During this whole time, it was not really possible to do any kind of real work on the specifications. The focus of the last two years was the actual transfer of the projects, the review of the legal question, and the creation of the new organizational structure instead. This was especially depressing to those, who wanted to help fairly early on with the development, but didn’t get a real opportunity to do so, and instead were told that they had to wait until all of the open issues regarding the development were solved.

To the future

And where do we stand today? Jakarta EE 8 has just been released. Above all else, this means that the Eclipse Foundation released a first version of the Java EE successor, which developed entirely out of the respective Eclipse projects and went through all of the phases of the new Jakarta EE specification process. For the new Jakarta EE, it’s a real stack-run. Now it seems that Jakarta EE can stand on its own and can look ahead.

However, this release is quite sobering from a technical perspective. Although Jakarta EE was released by a new organization, according to new rules and processes, the purely technical state is exactly the same as Java EE 8, which was presented to the public in 2017. And, if we are being honest, Java EE 8 was not exactly a big release. Because back in 2017 at the JavaOne Conference, Oracle announced they would remove a large portion of the planned features from the release plan. And although a whole set of new points had been added to Java EE 8 plan back then, in end almost none of the new features made it into the new release. This was quite disappointing, but the community was happy that there was a release at all though.

SEE ALSO: Jakarta EE 8: Past, Present, and Future

So it’s high time that Jakarta EE evolves and, above all, tackles the issues the community has been waiting for for years. There are more than enough candidates. The MicroProfile Project, for example, which already has a lot to show for in many different areas. Topics such as Health Checking, Configuration and Fault Tolerance have long been on the wish list of the Java Enterprise Community. But the long pending and better integration of the CDI into the different areas of the platform is also long overdue. Furthermore, the community has already gathered various suggestions that could theoretically be put on the agenda.

Starting problems

Here’s the crux of the matter: Unfortunately, even to this day a lot of the necessary prerequisites for further advancement are still not fulfilled. And this list is, regrettably, quite long. One problem there is, is the namespace. Because it is forbidden for the Eclipse Foundation to develop Jakarta EE in the well-known javax namespace, a transition to the jakarta namespace is inevitable. The difficulty and the possible strategies for implementation have been amply discussed in the last month. The advantages and disadvantages of the different variants are well known. However, until now no decision has been made regarding which of the methods will be used. Will Jakarta rename all packages in a big refactoring or will it go an incremental way, where only those packages will be renamed which really contains changes to the API? The final decision has been pending for many months. Of course the community hopes that this decision will finally be made after the Jakarta EE 8 release. Then this important issue, which mainly became a problem due to trademark law and affects Jakarta EE as well as the entire Java world, can finally be solved.

But regardless of that, a large part of the specification documents is still not available. These were allegedly transferred from Oracle to the Eclipse Foundation a few months ago. They have not yet arrived at the respective projects though. According to an Eclipse foundation statement, the documents should only be roughly checked by the IP team of the Foundation, until they are released for the publication in the source code repositories. Unfortunately, this has not yet happened. One possible explanation is that the documents were deliberately withheld to not jeopardize the Jakarta EE 8 release schedule.

SEE ALSO: Jakarta EE 8 – a new age of enterprise Java is upon us

For this release, it had already been decided to publish only “Boilerplate Specifications”, which contain only the rough structure of the actual documents, but no real content. It is obvious that this was just an emergency solution. If the Eclipse Foundation had provided real specification texts shortly before the planned release of Jakarta EE 8, a lot of work would have had to be done on the projects at short notice. In particular, incorporating the various new names of the specifications into the texts would probably have meant that the originally planned schedule could not have been met. So if this was really the reason for the delay in providing the texts, there would be no reason why the documents shouldn’t be published after the release.

The documents themselves are of enormous importance for the projects. In most cases, the new functions and specifications concern both the API (i.e. the classes, interfaces, javadocs, and so on), as well as the specification documents, and the TCK. Further sensible work can only be done, if all three of the artfifacts can be adapted properly. What happens if this is not possible can be seen quite well in JAX-RS. As one of the first projects, JAX-RS has already developed a new feature a few months ago with the Java SE Bootstrapping API. Due to the missing specification texts this function exists only within the API. All other adjustments have to be updated as soon as the project team is able to do so. So, of course, work piles up quickly, which has to be done at some point.

Divide et impera

There are also construction sites in the TCK area. At the moment, the Jakarta EE TCK is one gigantic repository and contains nearly 4.6 million lines of code. This is especially problematic for organizational reasons. At the time of the JCP, the specifications were responsible for their own TCKs, which were then all combined into the Java EE CTS. This resulting TCK package has been migrated as a whole to the Eclipse Foundation and is now called Jakarta EE TCK. In the future, however, it would make much more sense if each specification project had its own repository with the relevant parts of the TCK under its control. Only then the project team can work efficiently and expand the TCK step by step.

However, Jakarta EE is still far away from this optimal solution. Instead, it seems like the TCK is currently a rather closed project. And although there are over 300 commits, which proves that TCK is actively being worked on, there is hardly any significant communication on the mailing list.

Furthermore, it seems like it is mainly Oracle that is working on TCK. This can be explained by the fact that Oracle is most familiar with TCK, and therefore — at least currently — still takes on the majority of the work. Nevertheless, a solution has to be found urgently. If all the changes to the TCK should have to be transferred to a single repository via pull requests in the future, then this would quickly become a bottleneck and block any further progress. Unfortunately, splitting the TCK is not an easy task at all and will take some time certainly. Whichever way is chosen for the future of the TCK, the first steps should be taken promptly so that this issue can be taken further.

Despite all these points, I would like to mention once again that the Jakarta EE release is a great milestone and an enormous achievement of all who are involved. However, it must also be stated clearly that the Jakarta community is still far from being able to concentrate on the actual further development of the specifications. Let’s hope that we can now finally start to remove the last blockades and look optimistically to the future.

The post Jakarta EE 8: A critical examination of the first Java EE successor appeared first on JAXenter.