Have you already optimized your applications to reduce your impact on global warming? In addition to this, a new version of Gradle, a follow-up to last week’s edition.
1. What is the Carbon Footprint of your application? There is a tool to measure it
I enjoy listening to the airhacks.fm podcast by Adam Bien, it has become part of my morning routine while driving my daughter to daycare. The laid-back discussion style has the benefit of allowing guests to share a fair amount of loose thoughts. Ones that probably wouldn’t have room for in any other format than podcast “talking heads.” As an example, I throw in an episode from last October, in which, while discussing CRaC and Serverless, Adam suggested that the message of “reducing carbon footprint” was sometimes a better selling point for stack modernization for business than the somewhat touted “increasing efficiency.” At first, it was a bit surprising, but when I recall the rash of corporate messages about planned “zero-carbon”, it makes deep sense and for such Serverless can indeed be a compelling sales strategy.
Why did I even remember the quote from the 2022 podcast? Because last week saw the release of JoularJX 2.0. What is JoularJX? It’s a JVM agent for monitoring energy consumption at the JVM level, which allows developers to monitor and analyze the carbon footprint of applications on various computing devices and operating systems. Its models can estimate the energy consumption of hardware components, such as CPU and memory, and provides detailed reports and visualizations. And it does all this to help developers identify places in their software and optimize its power usage.
JoularJX 2.0 introduces a new feature that tracks power and energy consumption at the methods level, providing more accurate insight into the software’s energy efficiency. The release also reduces the overhead caused by JoularJX itself (it would be a bit sad if there was significant power consumption because of all that reporting, wouldn’t it?).
The conclusion can only be only one:
Sources
- Java, CraC and Reducing Cold Start Duration with AWS Lambda SnapStart
- joular/joularjx
- JoularJX 2.0: a Leap Forward in Green Software Analysis
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. Gradle 8.0 has been released
The beginning of the week saw the release of a new Gradle – now 8.0.
A lot of improvements have been made to the Kotlin DSL, an alternative syntax to the traditional (and more popular, more on that in a moment) Groovy DSL, providing better syntax hints for editing. With Gradle 8.0, script compilation has been improved by introducing an interpreter for declarative {} plugin blocks in .gradle.kts scripts, resulting in a 20% performance gain, bringing Kotlin DSL processing time closer to Gradle DSL. Gradle 8.0 also updates Kotlin API versions to the latest 1.8, and allows the use of Java 11 libraries and language features in compilation scripts. Unfortunately, this does not apply to pre-compiled plugins, only to gradle.kts itself.
It’s great that the developers are making sure that Kotlin support is as good as possible, but I’ll admit that even though I forcefully try to use a variant in this language, it’s terribly inconvenient despite the years. This is not the fault of Gradle itself – they do what they can, but for the community it is very inconvenient to create every example in two variants, so usually, all kinds of blog posts contain only a Groovy one. And while such a Maven Repository has already learned to present the Kotlin variant as well, I myself today came across, for example, the Lombok site, where all the examples are solely in Groovy. Unfortunately, the more non-trivial the case (and it is possible to create really complex stuff in Gradle), the more difficult the migration from one format to another.
The latest release of Gradle also introduces improvements for additional code locations passed via the buildSrc parameter, which are now expected to better support incremental compilation and caching, as well as received polished support while running tasks from the command line. Gradle also no longer automatically runs tests for buildSrc and its subprojects when they are not needed.
For more details, as well as additional changes in the 8.0 version, I refer you to Release Notes.
Even more interesting aspect of the new release than the changes themselves that come with it (you have to admit that, while nice, there’s hardly anything particularly spectacular there) is the bump up of the major versioning, which, as you can easily guess, is due to the broken backward compatibility with some aspects of the 7.x branch. As a result, there has been some criticism that from what, but from build tool most users require stability and compatibility. I understand such criticisms, yet acutely in this regard, Gradle has done a titanic job relative to how problematic upgrades were just a few years ago. When I was programming on Android at the time it initially adopted the tool, every time I updated Gradle builds (which was enforced by the incompatibility of old releases with new versions of the Android SDK plugin) it was a traumatic process. Today (at least for server applications) things are much better in this regard.
And while we’re on the subject of build tools, I’ll share with you at the end my probably favorite chapter from the book Software Engineering at Google – Build Systems and Build Philosophy. Using Bazel as an example, the book shows the complete opposite side of the coin to the extremely flexible Gradle. It makes clear the advantages and disadvantages of these two different philosophies of the application-building process.
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!
Bonus: Null Safety – Java vs Kotlin
Finally, a bit as a bonus, I have for you a publication that corresponds well with the main theme of the previous edition – the Valhalla Project’s attempts to improve the concept of nullability.
I suggested there that perhaps an option the JDK developers could possibly decide on would be to introduce some new annotation. This idea turned out to be a bit of a bummer, because literally the day before, Brian Goetz, Architect of Java, sent an email in which he makes it quite clear that the language itself should be free of annotations, and @Override as it was introduced was not the best idea. So the concept is unlikely to happen, even though it seems very natural. After all, there’s a reason we’ve had a rash of different variants of @NonNull over the years – there’s a need, apparently.
Nicolas Fränkel last week published the text Null safety: Kotlin vs. Java, in which he is tempted to compare how approaches to the Null concept differ between the two languages. As one element of his analysis, he summarizes the existing annotations on the market and lists eight different variants, having different packages and (even worse) slightly different behavior.
Looking at the above, it is worth pointing out the jSpecify initiative (also mentioned in Nicolas’ article). The participating players are working on defining a standardized set of annotations for static analysis, and have set @NonNulla as their first goal (looking at the above – very rightly so). It’s led by Google, and includes players such as VMWare, Microsoft and JetBrains, the creators of many of the above annotations, so they have the power to clean up the whole mess. Let’s keep our fingers crossed for them.
Sources
Discover more great content!
- Save time and effort
- Read handpicked articles
- Free yourself from spam
