Another week, another big release – this time the long-awaited Jakarta EE 10. In addition, the aftermath of the JDK 19 release and the GraalVM roadmap.
1. Will Jakarta EE compete with Microprofile for the hearts of microservices developers?
The seasonality of news in the JVM world is amazing (or not-so-awesome, since it probably correlates with the holiday period). Either nothing is going on in the community (as there could be in some July/August weeks), or every week we get a rash of news – such as the whole of September. Well, last week, the entire edition was devoted to the release of the fresh JDK 19, and today we have Jakarta EE 10 as the culmination of the last two years of work. While the last major release (Jakarta EE 9.1) focused on transitioning to a brand new namespace, “10” brings several significant functional updates.
If I had to point out the single most significant change in the new release, I would probably choose the new Jakarta EE Profile – Core. What are profiles? We used to have only one Java EE variant, which was simple but caused problems. The standard was broad, and to pass the certification, a given application server had to implement each new API, which increased the adoption time for each new version. That’s why JEE developers decided to create two profiles – Full and Web, where the latter was intended for typical Web applications.
This all happened in the era before we started packaging our applications in single deployable jars. This change – and a new generation of solutions – motivated further tightening o the number of crucial APIs to only necessary in such a use case. This is how the Jakarta EE-independent MicroProfile was created, and now its competitor(?) – the official Jakarta EE Core Profile. Why does Jakarta EE create its solution instead of getting along with Microprofile? TLDR: It’s related to the flexibility that MP developers crave, which Jakarta EE isn’t able to offer. That doesn’t mean there’s any conflict between the projects – but at the moment, Core Profile will provide a base that MicroProfile can expand upon.
Let’s now turn to the new features in the APIs themselves. We’ll start with Jakarta Context and Dependency Injection (CDI) 4.0. For years there has been a continuous slimming down of corporate Java, and the popular CDI has headed in this direction. Its structure has become, hmm… a bit complicated. In addition to the division into SE (for standard Java, used by Helidon, among others) and EE versions, more variants have now appeared – CDI Full and CDI Lite. The latter contains only the most key aspects of CDI. It was designed to support the need for popular libraries such as Dagger and Guice, leaving out more advanced functionality related to the lifecycle of injected dependencies. I suspect that for most of our readers, CDI Lite will be the target solution – it’s the one used by popular frameworks like Quarkus and Micronaut. If you are curious about a more extensive study, a very good one can be found at The Server Side.
CDI users will also be pleased to see another interesting change brought by Jakarta Concurrency 3.0. It introduced a CDI 4.0-compatible version of the @Asynchronous annotation, until now only working with EJBs. The result of methods annotated with @Asynchronous must be ComputableFuture, and in addition we have the ability to specify the thread field on which executions are to take place. This represents a step forward from the variant of the old Enterprise Java Beans, which forced the use of a pool defined by the application server.
Getting off the topic of dependency injection – Jakarta Security 3.0 brings long-awaited OpenID Connect support, which will surely please application developers using third-party identity providers for user authentication. Meanwhile, Jakarta RESTful Web Services 3.1 brings the Java SE Bootstrap API – that is, the ability to use Rest services for testing, for example. After years of waiting, we also lived to see official support for UUID as a data type in the Jakarta Persistent API, as the now widely known JPA acronym evolves.
The whole thing is topped off by an update to Jakarta Faces, the fourth version of which is released as part of JEE 10. The biggest change is a move away from EJB toward the aforementioned CDI. Creating HTML views directly from java code is also to be made easier – a dedicated API has been created for that purpose. Will this be enough to win back the heart of the community, which has lost its interest in the project? Recently, there have been some positive reviews on the web about the path the project has taken. Still, from my perspective, it’s unlikely that even the return of Server-Side Rendering fashions will be enough for us to see mass adoption.
Jakarta Faces has positioned itself from the beginning as a solution that allows Java developers to create full-stack applications, even without proficiency in JavaScript. Therefore, at the end of the Jakarta section, I couldn’t help but mention the appeal that Ryan Dahl – the creator of Node.js – made to Oracle. Due to historical and legal complexities, Oracle owns the rights to the name (and trademark) of JavaScript, which is very much out of favor with the project community. The same risks that forced the community to migrate from Java EE branding to Jakarta EE for a long time are pointed out – one day Oracle may decide to defend its trademark, and already today, the name is something highly toxic for many entities afraid to step on Larry Ellison’s corporation.
Sources
- Jakarta EE 10 Released
- Node.js creator Ryan Dahl urges Oracle to release JavaScript trademark
- Are You Crazy Still Using JSF!
- Using java for the front-end of a web app in 2022
- Jakarta EE 10 Platform, Web Profile, and New Core Profile Specifications Are Finally Out!
- Jakarta EE Ambassadors Joint Position on Jakarta EE and MicroProfile Alignment
Discover more IT content selected for you
In Vived, you will find articles handpicked by devs.
Download the app and read the good stuff!
2. JDK 19 – alternative distributions, security and Garbage Collectors
A week ago, there has been the launch of the new JDK, which means there was no shortage of regular “side events.”
Let’s start with variants of the official JDK, which have started to appear very quickly. Corretto (JDK from Amazon) version 19 is now available on AWS and for download for local use. BellSoft has also announced the release of its edition of their Liberica JDK. However, while the version is still available on the Downloads page, for some reason, the post announcing it has disappeared at the time of this writing… could it be that the launch turned out to be a false start? If you’re a Liberica user, I suggest you hold off on updating for a while yet.
It will probably make little difference to most developers whether their application runs with OpenJDK, Liberica JDK, Correto, or Azul. However, apart from the new features we described a week ago, each Java release also brings quite a few fixes under the hood, often in areas such as security or performance. Fortunately, these more heavily specialized aspects of the platform have their champions. The first of these is Sean Mullan, who tirelessly publishes an overview of what has changed in a given JDK release every six months in such aspects as security, cryptography, and all the related tooling. Thus, “nineteen” brings, among other things, increasing the length (and thus increasing the difficulty of a potential attack) of keys for basic encryption algorithms or improving TLS performance. There is also no shortage of some improvements in tooling, and the icing on the cake is the relegation of several algorithms, including the ever-popular MD5, to the category of Legacy ones.
And at the very end, Thomas Schatzl and his overview of what’s new in Garbage Collectors. The period when successive releases of the JDK have been showing new JEPs in this category is probably behind us (at least for a while), but that doesn’t mean that absolutely nothing interesting has cropped up in this area. After all, the star of the new Java release was virtual threads, with performance characteristics that differ sharply from the concurrency JVM users were accustomed to. Indeed, it turns out that the inclusion of Loom (which, I remind you, is in the test version) causes significant complexity in the garbage collecting process. That resulted in the need to speed up the deprecation of the so-called sweeper. Overall, there are about two hundred minor and major fixes, and a list can be found in the official JDK tracker. Thomas’ post also brings a bit of future perspective – we can expect a significant G1 refactoring in JDK 20, which he elaborated about on his blog in early August.
Sources
Discover more IT content selected for you
In Vived, you will find articles handpicked by devs.
Download the app and read the good stuff!
3. Official GraalVM roadmap published
And finally, a roadmap! And not just any roadmap, as the GraalVM team decided to share the project’s future with the community. What did we learn from the developers’ plans?
GraalVM Roadmap is divided into two categories – changes to the native images (and their compiler) and the project runtime environment. The Roadmap is also very nice to consume, as it uses native GitHub’s project management functionality (this is one of the first projects where I see this).
But form is form, content matters. The roadmap gives a sneak peek at what to expect from the new major release of GraalVM, coming October 25. Regarding runtime, support for LLVM on Windows and node.js for M1 has ended. There will also be patches for Python and Ruby. However, we’ll look at all this at the official launch.
However, even more exciting things will be found in the compiler tab. This is because it turned out that GraalVM will get full support for virtual threads, which appeared in the recently released JDK 19. Interestingly, it turns out that the original support for the flagship Project Loom initiative appeared a while back. Still, in the JDK itself, the developers made some changes that GraalVM had to adapt. On the other hand, the second very interesting aspect is the beginning of work on an official API for all external tools that want to enrich GraalVM tooling. Until now, they have had to rummage through internals, which is risky for the project’s long-term plans.
sun.misc.Unsafe.The entire roadmap goes beyond the current release. We learn from it about plans to better support ZGC, JFR, AWT, and other technologies from Core Java. There are plans to introduce a mechanism to allow partial initialization of applications during image development or the opening of Ideal Graph Visualizer – a developer tool that allows the analysis of compilation graphs and investigation of performance problems – sources. So far, this one has only been available in Enterprise editions, but now it’s set to make its way to the Community Edition. Of course, there’s much more, but we’ll be sure to report on that as plans begin to crystallize. Exciting times ahead for GraalVM.
And as for Virtual Threads – a new episode of the Inside Java Newscast reviews the tools that have gained support for Virtual Threads. I highly recommend watching – after a brief introduction to Loom itself, the real meat begins from about the fourth minute. There’s even more to it than I expected, and I thought I was following the topic closely – I also recommend it.
Sources
Discover more great content!
- Save time and effort
- Read handpicked articles
- Free yourself from spam
