Jakarta EE 8 is sprinting towards an exciting future for enterprise Java

The first release is called “Jakarta EE 8” and will be released on September 10th. To celebrate, developers can attend a virtual online conference – no less than 19 one-hour contributions will be streamed online (and made available on the Eclipse Foundation’s YouTube channel later). Among the speakers are numerous internationally renowned Java Enterprise experts.

Jakarta EE 8 – as you can probably tell from the name – is functionally identical to Java EE 8, which was published two years ago. So, you might think that not much has happened in the meantime, but in fact the move of the Java EE platform to the Eclipse Foundation involved considerable effort; large amounts of code had to be migrated to a new build infrastructure. This includes the previous reference implementation “Glassfish” as well as the TCKs (Technology Compatibility Kits) which are now available as open source. Allegedly, these are a total of about 5.5 million lines of code and over 2.2 million comment lines in more than 61,000 files. This would be comparable with the backend of World of Warcraft and Linux kernel 2.6.0. It is therefore not a success to be underestimated if, with the release of Eclipse Glassfish 5.1, an application server compatible with Java EE 8 could be built on the infrastructure of the Eclipse Foundation and its compatibility could be proven with the help of the TCKs.

But that’s not all. In addition, difficult legal negotiations were conducted behind the scenes, and trademark and usage rights in particular were negotiated. The specification documents of the individual Java EE technologies were transferred to the Eclipse Foundation, and a new specification process called EFSP (Eclipse Foundation Specification Process) was passed, which will replace the JCP in the future. The EFSP stipulates, among other things, that there should no longer be so-called Spec Leads, that new features should be developed with a “code first” approach instead of starting with the specification document, and that there should be “several compatible implementations” instead of a single reference implementation.

Over the course of the transfer to the Eclipse Foundation, the individual Java EE technologies also had to be renamed. Therefore it is no longer called “Java Servlet”, but “Jakarta Servlet” and so on. While this renaming may be perceived as annoying here and there, it also has a positive aspect: time was spent ensuring the names of the technologies were standardized and also simplified in part. Until now, the names were quite inconsistent. Where previously we had such inconsistencies as “Java Architecuture for XML Binding”, but “Java API for JSON Binding”, the new names in this particular case are now “Jakarta XML Binding” and “Jakarta JSON Binding”. The recognition value of the new names can be rated as very good overall.

What next for Jakarta EE?

Now that the first release of Jakarta EE is available, the long-awaited further development of the platform can finally begin. Many developers hope for a general modernization and new features, especially for the development of microservices and for modern operating variants, such as cloud or Kubernetes.

Within the MicroProfile project, a number of interesting suggestions have already been developed, most of which already show good stability. After all, MicroProfile version 3.0 is already available, and various implementations are available for developers to download. These new features include support for metrics, heath checks and OpenTracing, support for OpenAPI, and extensions to improve the robustness of applications (Timeout, Retry, Fallback, Circuit Breaker, Bulkhead). Another useful innovation is the implementation of a Config API, which allows configuration parameters from different sources to be injected directly into the application code. The configuration sources can be a file, environment variables, system properties or proprietary sources such as a database table. The support of such proprietary sources is easily achieved by implementing a Service Provider Interface (SPI). The MicroProfile implementation automatically searches all available sources for a suitable configuration value when a configuration parameter is injected.

SEE ALSO: Jakarta EE 8 release – the future is now!

It would therefore be obvious and desirable to migrate MicroProfile’s innovations to Jakarta EE step by step. Since MicroProfile’s development is already quite advanced, it should be possible to achieve this in a timely manner from a technical point of view. And further interesting innovations can already be found on the MicroProfile roadmap. There you will find support for Reactive Streams, GraphQL, Event Data or reactive access to relational databases. Apart from MicroProfile, however, some new features have also been advanced in some of the existing technologies, such as JAX-RS, which could also soon be incorporated into the platform. In this context it should also be mentioned that Jakarta EE will have a much shorter release cycle. Similar to what happened in Java SE, there will be more frequent releases, which will only bring minor changes. It is to be hoped that a version of Jakarta EE with new features will be released in the near future.

In addition to new features, application development in general and the introduction to the platform should also be simplified. Again MicroProfile offers a possible way; a “MicroProfile Starter” website has already been made available – very similar to that of Spring Boot. It can also be generally observed that many of MicroProfile’s concepts are copied from other frameworks. However, this is not necessarily negative: Why shouldn’t ideas that have proven themselves elsewhere be adopted? On the contrary, the recognition value makes it easier to find one’s way around in a new (old) environment.

After all, a departure from the original deployment model has long been apparent. The days when monolithic application servers were installed on a powerful server and several Java Enterprise applications were deployed there are definitely a thing of the past. They no longer fit in with current trends such as the cloud or Docker. Over the years, it has become apparent that in many places only a single application is deployed to an application server, which in turn raises the question of why this application server must actually support all Java EE technologies. On the other hand, it would be sufficient if only the technologies actually required by this single deployed application were supported. In view of this development in operations, the manufacturers of application servers have long since modularized their products to such an extent that a custom-fit variant of an application server can be built or configured for each application. The keyword here is “Just Enough App Server”. Build plug-ins are also available for Maven, for example, which pack the necessary application server modules together with the application into a single executable JAR file. A model that is much more compatible with Docker and the cloud – and has also been demonstrated by other frameworks.

SEE ALSO: Jakarta EE & Eclipse MicroProfile – ongoing discussions

Despite all modernization and further development, one of the central advantages of the past is to be maintained in the future: It is planned to maintain backward compatibility as far as possible, so that older applications can also run on current Jakarta EE implementations. However, as in the case of Java SE, it is planned to cut off some of the oldest bits and pieces, and to remove individual technologies from the platform in the medium term, or at least to mark them as optional. This should mainly concern APIs, which have always been quite exotic and are only used comparatively rarely.

One last thing…

So there’s a lot to do. Unfortunately, there is one last obstacle to Jakarta EE’s development: an extension of the platform would inevitably result in an extension of the existing APIs. Oracle has, however, only approved the use of the existing javax.enterprise.* packages in an unchanged state. In the event of a change or extension, the brand name “java” may no longer be used. This effectively prevents further development of Jakarta EE while maintaining the current package structure.

Finding a new package name was still quite easy (e.g. “jakarta.*” and “jakarta.servlet“). How exactly the conversion should be done is still under discussion. If the underlying Java APIs are moved to new packages, all existing applications will inevitably become incompatible. So what to do?

First it has to be clarified whether the changeover for all Jakarta EE APIs will take place in a single hard cut, or whether the new package names will be introduced step by step. In each release, only the actually changed APIs could move to new packages. So far nothing has been decided. But if the advocates of a hard cut should prevail, then the next release, “Jakarta EE 9”, would probably contain this change to the new packages as the only innovation, while new features would only be expected from “Jakarta EE 10”. Fortunately, as already mentioned, much shorter release cycles are planned than usual for Java EE.

One related question is how best to support companies and developers in migrating existing Java EE applications. On the one hand, it would be possible to offer tools or IDE features that automatically rewrite all package dependencies of an existing application project to the new packages. This would still be comparatively easy to implement at code level, but could lead to greater difficulties with dependencies to external libraries. Another suggestion already made is that containers such as Thorntail, Glassfish, or OpenLiberty map old packages to new ones internally at runtime, making them completely transparent to application developers.

Conclusion

With the release of Jakarta EE 8, a very important milestone has been reached for the platform. The problem of package names remains to be solved, then the modernization and the addition of new features can finally start. This is good news for companies that have numerous Java EE-based applications in productive use. But even for the development of new applications, Spring Boot may not be the undisputed top dog in the future. A whole series of exciting new frameworks, such as Quarkus and Micronaut, are on the march in MicroProfile’s sphere of influence. It should be an exciting competition.

The post Jakarta EE 8 is sprinting towards an exciting future for enterprise Java appeared first on JAXenter.