Helidon Nima – First Framework built from the ground up for Project Loom – JVM Weekly #101

After the previous one, heavily packed with content, today’s edition will be a bit shorter – the IT world is still on vacation. However, I have one exciting release for you and one no less attractive even-yet-not-release. Enjoy your reading!

Article cover

1. Helidon Nima – First Framework built from the ground up for Project Loom

Are you familiar with EclipseCon? It’s an annual conference held in Germany, which deals not only with the Eclipse IDE (as one might suspect at first glance) but with all projects under the Eclipse Foundation “umbrella.” And since this one has been seizing a mass of projects in recent years, it’s getting more interesting each year. Out of the mass of captivating talks, however, one stands out, with a notable name: Helidon Nima – Loom-based microservices framework.

I hope this is what your reaction is.

It turns out that we are getting ready for the first(?) framework in which Loom will not be a tacked-on add-on but a “First-Class Citizen”. For now, the details themselves are rather sparse (the abstract from ElipseCon is the only official mention of Nim), on the other hand…. early this week, Nina’s source code was released as part of the Helidon repository. So, if anyone feels like it, you can see for themselves what kind of API its developers want to offer us.

Overall, it’s going to be interesting this October. First JavaOne (17-20.10 – the event has already received a video announcement in Inside Java Newscast with an overview of the agenda), and then EclipseCon (24-27.10). Are any of our readers going to any of them?


Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

2. Release Radar: slf4j 2.0

We’ve talked a little about the future of Java, now it’s time to look a little at its present.

Or maybe even the past, but #NoSpoilers.

I suspect that virtually everyone reading this newsletter (at least those who have been in the industry for a couple of years) has had the pleasure of using the slf4j project at least once. The name is being rolled out as The Simple Logging Facade for Java, and that is its role – just as, for example, Hibernate provides abstractions over databases, slf4j hides implementation details of frameworks from the user. A decade ago, log4j, in its first version, was a heavily complicated framework with an annoyingly low-level API. Its main competitor remained relatively limited in configuration java.util.logging, while slf4j was a very convenient abstraction, giving the programmer, for example, powerful control over logging levels.

As an aside – do you know any Java project older than one year that doesn’t have its LogUtils class?

Since the heyday of slf4j, however, the industry has evolved a bit. First came Logback, which delighted developers with its instant initialization (making it easier to use directly, without additional abstraction), and then came log4j2, which brought an API compatible with slf4j, but already without the additional overhead of abstraction. In the meantime, java.lang.system.Logger appeared – being the JDK developers’ second approach to the topic of logging (a much more successful one). More and more people are leaning towards the fact that, in the age of mature logging solutions, it doesn’t make much sense to use an additional abstraction – even incidents like log4shell do not convince people that it’s worth changing the logger just like that. All of this adds up to the fact that slf4j’s glory years are probably behind it.

This does not mean, however, that the project is standing still, as its edition 2.0.0 appeared at the beginning of the week. Some changes have been made to the API (particular builders have been heavily remodeled, and Fluent Logging API has been added). Still, undoubtedly, the most significant revolution has happened under the hood. With the new version, slf4j got rid of support for JDKs smaller than JDK 8 – so they’re not as “ambitious” as the developers of, for example, Spring, but also because of its strong roots in the past, it’s a reasonably reasonable step. Altogether, those using newer JDK 9+ will also gain a lot from the migration – as slf4j lived to see support for JPMS modules, making it easier to use in modularized projects.

If you want more, a very interesting discussion about log4j2 vs slf4j can be found in a thread on StackOverflow