JVM Weekly #9 - Post-Holiday flood of topics 🤯
JVM Weekly #9 - Post-Holiday flood of topics 🤯
Hello after the vacation 😎 We have accumulated a lot of topics over the past two weeks, so now it's time to summarize everything.
1. Java 1.7 comes to an end ☠️
Currently, there is a lot of fuzz in Java Community about the slow death of Java 8. However, the amount of code stuck on JDK 8 is nothing compared to how many projects have ended their development on JDK 7. Java 7 usage is slowly becoming rather homeopathic (according to various reports, it is still used by between one and five percent of applications). However, there is still a lot of legacy code written in it. That code is waiting for migration and simply needed hmmm... proper motivation.
Oracle has presented such an offer as the end of July saw the termination of Extended Support for Java 7. As defined by Oracle's Lifetime Support Policy, 'Seven' is now moving into Sustaining Support mode. What does this mean in practice? No further patch updates, bug and security fixes, or feature implementations will be delivered. The only thing Sustaining Support gives you is the (very expensive) guarantee that if there is suddenly a massive problem with your version of Java, you basically... have someone to call - Oracle doesn't guarantee that this problem will be solved. However, the big companies historically go to their loyal, paying customers' lengths. As an example: Microsoft in June this year released the first new patch for Windows XP since 2017 for all those who still use that system, probably in ATMs or similar devices.
Sources
2. GraalVM makes it easy to work with external libraries
We've talked about JVM's past, it's time to look to its future. And no other project captures such a future better than GraalVM, a regularly developed alternative virtual machine for Java (and not only Java). With the regularity of a Swiss watch, new editions of it are delivered by the Release Train, and last week we received version 22.2. What does it bring?
The first big thing is modularisation. Up to now, no matter which of the many languages supported by GraalVM we used (in probably 90% of cases, it is Java, though), the base image contained the files necessary to run, for example, JavaScript or LLVM, and tooling like VisualVM. On the other hand, support for Python or Ruby needs to be directly added to the project. Now the situation has been tidied up and each of the additional modules has to be pre-installed - the "bare" GraalVM only supports Java. The advantage: the base image size has been heavily reduced at the expense of a few extra commands for LLVM or JS developers. For the greater good.
That's not all, of course. The new GraalVM also means better support for external libraries. GraalVM creates a static image containing pre-compiled classes, and at the final stages of the build, it is forced to clean up those non-used classes from the final artifact. While this sounds reasonable, the reflection mechanism has become quite rampant in Java, which makes it possible for an application to reference arbitrarily any class available on the classpath, so such a cleaning can cause runtime errors. Luckily, we can pass GraalVM a list of classes that should not be wiped out (Android developers are probably familiar with this mechanism from ProGuard). In the case of third-party libraries, however, this led to duplication of work when each project had to do it independently. Therefore, with the new GraalVM came the GraalVM Reachability Metadata Repository, a community hub for sharing such definitions - a bit like I existing one for TypeScript types. Most importantly - GraalVM Native Build Tools can be configured to pull in definitions for dependencies found in the code automatically.
The new GraalVM also includes a few other features - the ability to generate ThreadDumps more easily, optimisations and performance fixes, or Apple Silicon support (because since the M2 release, it's hard to use the name M1 anymore) in GraalVM Enterprise. For more details, I invite you to read the new release's post.
Sources
3. New Intellij Idea 2022.2 makes macOS users happy
I don't know if there is a single person consciously reading this series who doesn't associate what IntelliJ Idea is. The creators of the best (I think I can use that word, and I'm not facing a lynching, right?) IDE for Java regularly releases new versions of their tool while managing to make each successive edition interesting. This time is no different, especially as, in addition to the new features, there have been some really big changes "under the hood" - especially for macOS users.
This is because IntelliJ Idea 2022.2, released yesterday, introduces a new version of JetBrainsRuntime, a fork of OpenJDK maintained by JetBrains. I don't know if everyone knows that although Idea is written in Java, it no longer uses the version of the JDK installed on the system for a long time, instead operating on its own, forked version. However, due to being a fork, it often lags behind Java's capabilities. For example, the version of JBR shipped so far was based on JDK 11, so it could not consume the changes that have gone into Java over the last couple of years. This will now change.
At this point, you are probably wondering what changes might be relevant from an IDE point of view. JetBrainsRuntime version 17 brings, among other things, support for Project Lanai, the JetBrains-led initiative to "marry" Java with the Metal API, the (no longer so) new rendering pipeline for macOS. The previously used OpenGL has long been out of the Cupertino company's sights. At the same time, Metal is being developed regularly, effectively consuming all the innovations introduced in the MacBook hardware - and there have been a bunch of those lately (M1, anyone?). JetBrains boasts a significant performance boost on Apple Silicon, although I haven't caught up with specific benchmarks anywhere. JBR17 also brings the company's first experiments with the Vector API, part of Project Panama, which allows direct access to hardware, with java abstraction (almost) bypassed.
But what does the new IntelliJ bring, apart from the improved performance? Remote development seems to be the apple of the company's eye and has received further improvements in the new IDE. Despite remaining in Beta, support for working via SSH on a remote machine has been improved, as well as the JetBrains Gateway, which JetBrains sees as a new center for our remote work, a thin client allowing us to manage external environments. There were also quite a few improvements for those lucky enough to have access to the closed beta of JetBrains Spaces, a direct competitor to VSCode.
Spring users will also be happy - as IntelliJ from now on supports the upcoming Spring 6 and Spring Boot 3, due for release this autumn, which have been available in test versions for some time. The company has also increased compatibility with its own Kotlin 1.7 or Groovy 4 features support. There will also be no shortage of new code inspections. Overall, if you are curious about the complete list of changes, I encourage you to check out the full changelog.
For the sake of completeness in this post - the Plugin for Scala has also received its new version. This one got the standard changes, such as new Scala capabilities and automatic refactorings. The most exciting addition seems to be the possibility to use an external Error Highlighter.
Finally, a spoonful of tar. Writing about the new version of Idea is an excellent opportunity to remind you that JetBrains announced an increase in the price of its subscriptions from 1 October a couple of weeks ago.
Sources
4. Vert.x developers start experimenting with Project Loom
The Loom project is gaining ground. A few editions ago, we described the first experiments of the Quarkus developers with this technology, while the end of July brought an announcement from the creators of Vert.x. This experimental project, which was initially positioned as an alternative to Node.js on the JVM, is currently an incubator for concepts related to reactive and asynchronous programming on the JVM - suffice it to say that, for example, Hibernate Reactive is actually an overlay over the reactive database drivers developed within Vert.x.
Now the framework takes on a new task - creating a reference version of how to use virtual threads for reactive systems. Loom is a very internal functionality - what you get with the project is a building block for framework developers, whose task now is to create abstractions that will only be used by 'industrial developers'’ Here comes Vert.x and their announcement of the Virtual threads incubator, a project that aims to provide ready-made solutions and patterns. At the moment, the first of the proposals is Vert.x Async/Await, but we should be getting more soon. I will follow the updates in the repository vert-x3/vertx-virtual-threads-incubator, and when more proposals appear, they will undoubtedly make their way into this newsletter.
Sources
5. Helidon 3.0
Finally, we have a new release of Helidon for you - edition 3.0. Although the framework remains somewhat in the shadow of more popular solutions such as Spring, Micronaut or Quarkus, Helidon is a kind of reference implementation for MicroProfile and the 'micro' Jakarta EE from Oracle itself. We, therefore, take a look at what the new version brings.
And here's where the first surprise comes - the new release requires a minimum of JDK 17 to work. Oracle is going like a storm - as you can see from the attached example, they have adopted a carrot and stick method (minimum supported releases) - you can use significant new features (carrot) if you migrate yourself to JDK17 (stick).
Such a "significant new feature" can undoubtedly be considered support for MicroProfile 5.0 and selected aspects of Jakarta EE 9.1. In a way, I find it amusing that with this bump, the framework from Oracle is getting rid of the trademarked javax. package in favor of jakarta package. The developers boast that this is the first corporate product to make this change. Helidon also brings JEP 290: Filter Incoming Serialisation Data security improvements during the serialization and deserialization process (which is disabled by default in Helidon 3.0, by the way), as well as improvements to the routing API.
However, it is not only the new capabilities of the framework itself that are important but also how it is used (what is a lesson often forgotten by the developers of the Vert.x mentioned above, which has “legendarily” terrible documentation and release notes). The new Helidon also brings improvements in the context of Developer Experience. With the new version, we get a new project generator - both in the web version, which allows easy configuration of the base for a Helidon project (similar to the ones from Spring or Microprofile) and in CLI form, for those who prefer the terminal.
Source
6. Micronaut 3.6.0
The second of this week's news is the release of the new Micronaut. What does the release of Micronaut 3.6.0 bring?
It's only been a week since I wrote about the new GraalVM, and it's already hit Micronaut. Admittedly, the developers don't boast about what novelties directly for their framework are behind it. Still, the very fact of the introduction of fixes given by the underlying GraalVM (library repository ❤️) means that those using the "native" Micronaut shouldn't hesitate for long to migrate.
But what for those who have not yet jumped on the GraalVM bandwagon? For them, a new module - Micronaut Test Resources - adds support for managing external resources needed for testing. The module itself basically provides integration with Testcontainers, requiring no additional configuration. This allows Micronaut to fire up the necessary database instances by itself, for example. All major systems - e.g. PostgreSQL, MongoDB, Kafka, Redis, or ElasticSearch - are supported. In addition, the developers have provided two plug-ins - one for Gradle, and the other for Maven - to enable the configuration of this functionality.
It is a variety of integrations, by the way, that the new Micronaut release stands for. In addition to the above, Micronaut Tracing received support for the OpenTelemetry format, making it immediately compatible with the most popular market solutions. Support for Hibernate Reactive has also been added within the Micronaut Data module. It also allows Hibernate Reactive to be selected at the project generation level. And if you have long since switched to jOOQ, this too has been upgraded to the latest version - also the first entirely reactive version - as part of the new release.
