Java community seeks happiness beyond Twitter. Want to join? - JVM Weekly #113

1. Removal of Technical Debt from JDK continues

Let’s start with the new features coming in JDK 20. There’s not that much of it this time, so we’ll focus instead on the so-called “Quality Outreach Heads-Ups” – clearing of technical debt by JDK developers. We discussed discarding the ability to compile to a byte of JDK 1.7-compatible code when it was announced back in September, and now it’s time to look at the rest, as we’re in for some surprises.

You probably all know that Thread class in Java has quite a few helper methods – and hopefully, you haven’t had to use them. I still remember learning Java from the classic Thinking in Java by Bruce Eckel, which scared me for years to even think about writing any asynchronicity in Java. Thread.wait(), Thread.join() and Thread.notify(), for low-level concurrency management always seemed very grubby to me, and I’m very glad that java.util.concurrent was added in JDK 1.5. However, the clarity of the API provided by Thread was further damaged by the fact that the class also provided additional methods – Thread.stop(), Thread.suspend(), Thread.resume(), which, as it turns out, had already been deprecated since JDK 1.2. Now, at last, it was time to get rid of them. According to announcements, this will happen right in JDK 20. For more details, see Java Thread Primitive Deprecation.

This just goes to show how much focus JDK developers have for backward compatibility

The last of the removed features is the clearing of the no longer-needed Multithreaded Custom Class Loaders. This was a kind of workaround – an intermediate step that was necessary to migrate some applications to the new Class Loaders architecture introduced back in the JDK 1.7. Now – as the remnants of the 1.7 version have been gotten rid of from the platform – it is also time to deprecate and disable the mentioned Class Loaders.

Maybe by the time of JDK 30 we will get rid of them from the project.

What else besides that? New JEPs associated with Project Loom. But before you get too carried away with your imagination, the second preview of Virtual Threads and the second incubation of Structure Concurrency don’t bring any particularly big changes. It’s just that a few APIs being part of the proposal’s previous iteration (such as ExecutorService extending the AutoCloseable interface) have been stabilized. Now, as they were migrated into the production JDK codebase, making it natural for them to disappear from the JEPs. The Thread-related changes I wrote about in the previous paragraph were also transferred to JEPs. In addition, work on both proposals did not advance in an externally observable way.

And if you’re disappointed by the changes in Loom, I wanted to communicate that Project Valhalla has recently awakened from its winter (or rather, autumn-summer) slumber, and hopefully, we’ll see some bigger announcements soon. But after so warming your appetites, I’ll save that for another occasion.

Source

2. foojay.io creates Mastodon server for Java Developers

I don’t want to write too much about what’s going on in Twitter – for one thing, that’s what I get my Saturday reviews in Software Craftsmanship Weekly for (which I encourage you to read), and for another, I think we’re all a little sick of the drama. I mention it, however, because the issue has grafted itself onto the Java world in a rather interesting way.

Well – at least at the level of communication – we are witnessing a great retreat from Twitter. In fact, the entire tech world has begun to look around for an alternative to Elon Musk’s platform. One of the main contenders to the throne seems to be Mastodon. If we consider – as media coverage would have us believe – Twitter as one person’s private manor, Mastodon is a federated platform. That is, it has no main feed (although mastodon.social is positioned as such), and the user experience is built by the many different communities you can join to. This week, foojay.io, one of the largest (and best) portals covering JDK-related topics decided to join the train. In no time at all (it took less than 48h from proposal to launch) they created their own Community foojay.social, to which they invite users. I also joined and I plan to contribute a bit there myself.

Being a devil’s advocate – Ben Thompson (author of Stratechery) argues that it is very difficult to replicate the core value of Twitter, which is a great “equalizer” that enables discourse with “the biggest” of this world. And – unfortunately – it pairs rather poorly with the Mastodon federation model.

If you want to learn more about what Mastodon is – a recent text on this topic was written by Martin Fowler himself. It’s also worth mentioning in that Twitter, too, for some time now has allowed the creation of discussion groups centered around a single theme. For example, here you can find a Java one, which is seemingly active – although I have the impression that it is rather used mainly to promote the creators’ own material about the language (guilty as charged). The whole thing, however, can give you a foretaste of what such a strictly thematic feed might look like.

The last thing I wanted to mention is Java Bubble – this is a community-maintained (specifically, by Marc R. Hoffmann) list of people who share their Java knowledge. If you were wondering who is worth following in the ecosystem – I think this is a good starting point.

Sources

3. Serverless service for Jakarte EE – Seriously

Nobody: Still Nobody: Payara: Let’s make Cloud Serverless for Jakarta EE!

I’ll admit that it’s been a long time since any headline surprised me as much as the news that Payara has decided to create Payara Cloud – Platform-as-a-Service for applications written in Jakrata EE. You can simply take your *.war compliant with the Jakarta Web Profile specification, upload it to the cloud and…. done. At first, all that popped into my head was “but why?” and I almost started scrolling further…. but yet it suddenly “clicked” and in retrospect, I find that it actually makes a lot of sense and fits well with the history of the platform that is Jakarta EE.

Because let’s face it – the Java EE standard was ultimately created to be able to separate the language from the specific implementation provided by individual vendors. So this kind of approach fits perfectly into the situation where infrastructure vendors are able to provide dedicated services to support Jakarta APIs. I know, today we pack it all in Dockers anyway, but that actually provides an additional layer of indirection over the kind of pure, scalable Serverless platform that Payara promises us. If we additionally look at Application Servers as a runtime environment for applications (which they basically are), the “I throw in a jar/war and forget about my cloud-native application” approach seems all too tempting. It’s just that once again, history has come full circle.

Sources

4. Quarkus announces its “third” edition with a bunch of interesting changes

Well, and to top it all off, we have perhaps the biggest announcement of the past week, that is, the ramp-up of the third version of Quarkus. Upgrading the major version always allows developers to take a big leap forward, and looking at the number of changes that are planned for the new Quarkus, its creators have eagerly taken advantage of this option.

Interestingly, the changes go beyond the standard bump up of API, library and platform versions, although there’s no shortage of those either. Indeed, the new Quarkus will bring Hibernate 6, Jakarte EE 10 (which, remember, wrecks compatibility), and MicroProfile 6 (whose release, by the way, we’re still waiting for). Under the hood, however, we’ll find a lot of much more interesting stuff.

The new Quarkus brings e.g. support for HTTP/3, which you may also know as Quic. This protocol can be simply described as an implementation of the standard request-response model known from HTTP, but based on UDP instead of TCP. As a result, it is supposed to provide much better performance for web applications that consume significant amounts of external resources. I’ll end here, but if you’re curious about more details – you can find a very good, 5-minute introduction here, and the post QUIC Is Not a TCP Replacement is a great resource going into the nuances and philosophy behind the new protocol.

As they said in school – “for the ambitious ones.”

io_uring support is another new feature that external materials will be useful for understanding. io_uring is a new (and realistically new – it hit the kernel in 2019) asynchronous I/O API for Linux created by Facebook’s Jens Axboe. I’ll admit that I’m intrigued by how the Quarkus developers want to use the whole thing, and I’ve figured out that Quarkus’ main Event Loop is likely to be modified. Although if anyone on the Quarkus team happens to be reading this: let me know in the comments – I’m intrigued.

Obviously, the new version of the Framework has to take into account the recent changes in the JDK, so Project Loom – Virtual Threads and Structured Concurrency – couldn’t be missing from the list of new features. This is what we all expected, but what caught my eye was the willingness to abandon Reactive Streams in favor of its implementation coming from JDK 9 – java.util.concurrent.Flow. Since Reactive Streams is the standard that Flow implements (Quarkus, by the way, uses an alternative called Mutiny), I wonder if this is some kind of mental shortcut for abandoning the aforementioned Mutiny or if something else is on the developers’ minds.

Again – a heartfelt request here for clarification 🙏

The last tidbit I came across in the announcement is the promise of “refactoring” documentation in the new format. This is because in the process I learned of the existence of a framework (conceptual one, not some kind of library) for creating user documentation called Diátaxis. The number of projects that have adopted it is quite substantial, and since the list will soon be joined by Quarkus as well, it’s probably high time to get interested in what it brings to the already existing array of good practices.

That’s not all, of course, as the developers, in keeping with the nature of RedHat’s framework, also promise us better performance and an improved “developer experience”. Interestingly, we can expect the whole thing pretty soon, as the final version is planned for February. You can be sure that on the occasion of the first versions of Alpha I will return to the topic

Java community seeks happiness beyond Twitter. Want to join? – JVM Weekly #113

1. Removal of Technical Debt from JDK continues

Source

2. foojay.io creates Mastodon server for Java Developers

Sources

3. Serverless service for Jakarte EE – Seriously

Sources

4. Quarkus announces its “third” edition with a bunch of interesting changes

Sources

Discover more great content!