"Measuring Energy Consumption in Programming Languages" with Miro Wengner - JVM Weekly vol. 147
Today, we have a guest post from Miro Wengner about energy consumption in programming languages, including Java.
Year ago I announced that JVM Weekly had joined the Friends of OpenJDK (Foojay.io) family. Foojay.io is a dynamic, community-driven platform for OpenJDK users, primarily Java and Kotlin enthusiasts. As a hub for the “Friends of OpenJDK,” Foojay.io gathers a rich collection of articles written by industry experts and active community members, offering valuable insights into the latest trends, tools, and practices within the OpenJDK ecosystem.
Today, we have something special… research paper, one in the topic that I fancy a lot - green technology 😊. Miro Wengner - member of the Java Community Process and Java Champion - put together a great benchmark comparing the energy efficiency of different programming languages in AI applications.
Research: Measuring Energy Consumption in Programming Languages for AI Applications
Decades ago, I contributed to a very interesting project called SunSPOT at SUN Microsystems. It was a small device with wireless connectivity, built-in sensors, running on Java (compatible with runtime 1.6), and powered by battery. It enabled the design of small applications and the connection of additional hardware, or simply the utilization of available sensors. Later, together with Markus Hirt, we created the Robo4j framework. A small and lightweight Java framework that enables rapid assembly of robots or other IoT systems (JDK 21+). In Robo4j, we primarily used the Pi4j project for handling I/O operations on the Raspberry Pi platform with drivers created for specific hardware.
A question that has been concerning me over the decades is: what is the actual energy consumption of such Java-based systems?
The unprecedented growth of artificial intelligence (AI) and applications utilizing agentic AI systems from various vendors has elevated my question about energy consumption to the next level.
Similar to Raspberry Pi development or AI agent implementation, Python serves as the primary language choice due to its simplicity for prototyping applications without requiring strict attention to type definitions. Working with hardware your obvious choice would be C and with utilizing an agentic AI system there is possibility to use JavaScript, which is a very nice functional language, to prototype initial experiments or applications. After my colleague at OpenValue published his hackathon’s simple energy consumption experiment, I became even more motivated to answer my question about energy consumption.
I created a fully automated framework in shell script that is capable of executing various runtimes and running parallel processes at the system level to obtain energy consumption measurements. I was eager to investigate how Java 21 and 17 compare against other languages like JavaScript, C, and Python. After gathering data and employing methodologies typically used in clinical studies, I acquired sufficient data to reach statistically significant conclusions.
The findings and conclusions have been added to my research article: ‘Measuring Energy Consumption in Programming Languages for AI Applications.
I would like to thank all the people who helped me shape this research, as acknowledged in the article’s Acknowledgments section.
I hope my research paper helps the community understand not only the importance of proper language platform selection, but also hardware choice considerations.
Since the Foojay piece is itself a teaser for another article, let me add a few words on why it’s worth your time.
First, the paper tackles a very current and important issue: the rising energy consumption of LLM-powered applications. Its goal is to give developers and companies practical guidance on choosing a programming language and hardware platform so their AI systems are not only fast, but also environmentally and economically sustainable. The methodology is clear: the study evaluates popular languages - Java (in various implementations), C, Python, and JavaScript (Node.js) - across diverse hardware, including Intel (Dell with Linux) and Arm architectures (Apple M1/M2 Max, and Raspberry Pi 4). The Arm results especially caught my eye (you know that’s my thing).
The computational benchmark uses a prime-number checking alg`orithm, providing a consistent, comparable workload. The findings are unambiguous: Arm-based platforms like Apple M1/M2 and Raspberry Pi 4 deliver significantly better energy efficiency than Intel-based systems. What’s more, across all tested hardware configurations, Java proved to be the most energy-efficient programming language - outclassing the competition, especially when leveraging parallel processing.
But as the author notes, the bigger picture is messier: companies still pay hyperscalers substantial infrastructure costs while providers burn through electricity, water for cooling, and scarce resources embedded in chip manufacturing - costs that are hard or impossible to truly mitigate. In that sense, there’s no real winner: customers fund the giants, the planet pays the externalities, and the non-deterministic nature of AI/LLMs further blurs whether the results justify the spend.
So if you’re looking for strong, data-backed arguments for choosing Java to build compute-intensive AI applications, this is absolutely worth a read. 😊
And now, let’s review some of the other cool things that appeared on Foojay.io last month 😁
Foojay Podcast #78: Welcome to OpenJDK 25!
As always with a new JDK release, we’ve got a Foojay podcast episode dedicated to it. Frank Delporte, together with his guests Simon Ritter and Balkrishna Rawool , enthusiastically welcomes the arrival of OpenJDK 25 - covering not only what’s new in this release, but also discussing how Java has evolved over the past 30 years. If you haven’t had a chance to watch Simon’s talk about the topic, I highly recommend this episode; and even if you have, Simon’s narration will help you place the latest changes in the right context.
PS: This is the new season beginnig, fifth one. Congratulation Frank for the consistancy (and quality) 🖖
And this is only beginning of JDK 25 related articles. Let’s continue.
Here’s Java 25, Ready to Perform to the Limit
Have you ever wondered how to reconcile the benefits of immutability with the need for flexible, deferred initialization of components? The article Here’s Java 25, Ready to Perform to the Limit presents the new release of Java can answer to these kinds of challenges. Hanno Embregts 🎤 🎸 focuses on a key novelty: “Stable Values,” a new preview mechanism that enables lazy loading of objects without sacrificing thread safety or the advantages of immutability. What’s more, the article highlights the importance of the expanded diagnostic tools in Java Flight Recorder, which now offer even more precise profiling and method tracing. Nice read.
From Zero to Vector Hero – Locally!
From Zero to Vector Hero – Locally! is a practical guide showing how a Java developer can build a complete Retrieval-Augmented Generation (RAG) pipeline entirely on a local machine. Arek Borucki smoothly leads from theory - explaining what embeddings are and why they’re crucial for the semantic understanding of data - to practice, where Testcontainers takes center stage, letting you spin up a local instance of a vector database, such as MongoDB Atlas, and begin experimenting with just a few lines of code.
The core message is simple: the barrier to building AI apps is now remarkably low. Instead of wrestling with cloud setup, a Java developer can prototype a full Retrieval-Augmented Generation pipeline locally and focus on application logic. The article works as a step-by-step playbook: demystify RAG, run everything on your machine, and leave with a concrete, working example you can extend in real projects.
And carrying on with MongoDB topic….
MongoDB Schemas in Java
Does the flexibility of a “schemaless” database like MongoDB have to mean chaos and unpredictability in a Java-based project? In his article MongoDB Schemas in Java, Luke Thompson argues the opposite - Java’s strong typing isn’t a problem but a powerful tool for taming that flexibility. He starts from a common issue: in fast-evolving applications, the lack of a rigid schema can lead to inconsistent data, runtime errors, and maintenance headaches. The article shows how to deliberately use Java’s type system to define a clear and safe document structure, shifting schema responsibility from the database directly into application code.
Overall, it’s a great deep dive - I’ll admit I was surprised by how much you can squeeze out of this topic.
Azul: 10,000 JVMs share optimizations, 20%+ cloud savings
In text by John Ceccarelli, Azul is bragging about a historic result: at a single customer, more than 10,000 JVMs are collaborating and sharing performance optimizations 🤯. All thanks to their Platform Prime with Optimizer Hub, which is said to deliver >20% cloud cost savings, faster application warm-up, and smoother autoscaling.
Yes, it sounds promotional, but the numbers and scale are impressive 😁
PS: OG title of article was Azul’s High-Performance Java Platform Achieves Historic First with 10,000 Customer JVMs Collaborating and Sharing Performance Optimizations, Cutting Cloud Costs by 20%, but I do not have that much space in headers 😉
Design Patterns Update to JDK 25
We started with Miro text and JDK 25 - so let’s do the nice wrap-up. Design Patterns Update to JDK 25 by Miro Wengner shows how modern Java features (pattern matching for switch, unnamed variables & patterns, compact source files/instance main) plus better JFR tooling (cooperative sampling, richer method timing/tracing) make classic design patterns leaner, clearer, and easier to test - nudging Java toward a more functional, readable style. Miro notes that his book Practical Design Patterns for Java Developers now has refreshed JDK 25 examples in a dedicated repo branch.
PS: Miro is also the author of Java AI Newsletter, which fifth episode was just published.
 | A guest post by
|