JVM Weekly #8 - Microsoft invests in Jakarta EE 🤯
In addition to this surprising news, we also have for you the ins and outs of incremental compilation. And for those who still have flashbacks from Dec 2021 - Log4Shell will stay with us for long...
1. Microsoft is investing in Jakarta EE (yes, we weren't wrong)
There are sometimes headlines where, after reading them, I have to do it all over again to ensure I got it right. At first, the news that Microsoft was becoming part of the standardization body for both Jakarta and MicroProfile seemed to me to be just.... somehow unrealistic.
The fact that Microsoft has recently invested much more heavily in its Java support is no-news to anyone. Gradually, the tentacles (but in a positive sense) of the Redmond-based company are infiltrating more and more organizations and foundations around Java, to mention the Eclipse Temurin working group or the Java Community Process. However, Jakarta EE is simply in a slightly different 'league'. Whereas previous efforts have mainly been directed at the possibility of influencing Java as a platform, Jakarta EE is already a very specific set of solutions, and its standardization body consists mainly of application server developers. Microsoft has become the only one of the large cloud vendors (I am not counting Oracle in this group) directly involved in developing enterprise Java.
And it is in the latter that the key to solving the above conundrum lies. Azure will be the first cloud to provide native Java application server services. Both WebLogic and WebSphere or JBoss EAP will be available today. Microsoft has also released a handful of guides on how to go about the process of such a migration to their cloud. It has to be said that this is a very interesting move and an attempt to compete directly not with Google and Amazon, but Oracle and RedHat. It also addresses the needs of large enterprise customers, and these are the ones who make up the bulk of Azure users.
But lest the whole thing focuses solely on Legacy apps - Microsoft has announced that Helidon, Quarkus, or Payara Micro will also become 'first-class citizens' within their platform. Thanks to the Maven plugin, the whole thing is also supposed to be easily relevant. You can find an example of the process e.g. Quarkus here. It looks quite nice.
Sources
2. A new approach to incremental Kotlin compilation
Despite being a rather unexciting release, Kotlin 1.7 has made some interesting additions to the language. One of these is an improvement in the incremental compilation. The topic of how long the build process is for Kotlin has been running through the language community (and these reviews) for years, and developers are also constantly tinkering with it. In fact, in every major release of the language, there are all sorts of announcements in this area. However, this is because Kotlin is, as a language, quite powerful and therefore also complex. Hence, standard optimization approaches that work well in Java will not do the job here.
Why. This is explained quite well by a new JetBrains publication with the clear title A New Approach to Incremental Compilation in Kotlin. If I had to compare it to something, we're talking about something akin to the standard Architecture Decision Record, but in a more virulent form for the general public. Here, we have a retrospective of the architectural challenges and differences from standard Java, and an explanation of why the compilation cache issue is much more complicated in the case of Kotlin (spoiler: a richer Application Binary Interface (ABI)). This required a lot of clever engineering from the language developers due to the need for the abandonment of the standard mechanisms provided by Gradle.
Sources
3. Log4Shell will stay with us for longer :(
And finally, a small return to the past. Do you still remember the apocalypse that was the discovery of a vulnerability in the popular log4j library? December oozed blood, and developers drenched themselves with caffeine due to overtime (and probably something much stronger at home). Everything because of the need for updating applications, sometimes including heavily legacy ones. Fortunately, the problem is now out of the way, and we can already forget about it, right?
Unfortunately, no. The Cyber Safety Review Board, a body advising the President of the United States, has analysed the situation and concluded that while no major attack exploiting the Log4j vulnerability has yet been detected, it is a matter of time. While the big update campaign has increased vigilance and delayed the first phase of exploitation of the library, there is still a huge amount of un-updated applications and servers worldwide, and the available versions on Maven Central are downloaded more than 100,000 times each week. Additionally, while the issue was high-profile, not all organizations took care, for example, to adequately trace the used versions of libraries and external applications, focusing instead on conquering Log4j in their code.
So we wait to see who will be the first real victim of Log4Shell. It is certainly easier to identify the winners of the whole situation - they are the corporate security departments, who have been given a very strong weapon in their hands when it comes to not using external dependencies.
