
Developing Performant, Cost Efficient, and Eco-friendly Code (#84)
Foojay.io | Friends of OpenJDK and Java ProgrammingShow Notes
In this Foojay Podcast, we're exploring a critical topic that's becoming increasingly important in our industry: developing sustainable software that is both performant and environmentally friendly. At the Devoxx and JFall conferences, I had fascinating conversations about how we as Java developers can make a real impact on both our cloud costs and our carbon footprint. And it's interesting to learn how these two goals are often perfectly aligned: what's good for your budget is usually good for the planet too. We start with Daniel Witkowski. He published an article on Foojay that takes us on a deep dive into performance tuning. He explains why optimizing your code can have a thousand times more impact than saving 30% on cloud costs, and walks us through his journey of turning a simple integer validation challenge into a masterclass on Java performance optimization. Next, I caught up with Ko Turk, who shares his passion for sustainable engineering and space exploration. He introduces us to Kepler, a tool for monitoring the energy consumption of your applications, and explains how performance optimization naturally leads to sustainability improvements. Then Ronald Dehuysser, founder of JobRunr, reveals how his open-source job-scheduling library now enables carbon-aware job processing. He explains how JobRunr can automatically schedule non-time-critical jobs to run when renewable energy is most available. And finally, Jan Ouwens joins us to discuss practical strategies for reducing both costs and CO2 emissions in your applications. He explains why cloud spending is actually a good proxy for your carbon footprint.
00:00 Introduction of topic and guests 02:07 Daniel Witkowski https://www.linkedin.com/in/danielwitkowski https://foojay.io/today/the-art-of-performance-tuning-why-saving-30-in-the-cloud-means-nothing-if-your-code-wastes-1000x-more/ https://foojay.io/today/foojay-podcast-83/ Why Saving 30% in the Cloud Means Nothing if Your Code Wastes 1000× More Performance tuning is less about syntax and more about craftsmanship. 29:46 Ko Turk https://www.linkedin.com/in/ko-turk-b271b929/ https://github.com/sustainable-computing-io/kepler Sustainable engineering Kubernetes Efficient Power Level Exporter (Kepler) 32:46 Ronald Dehuysser https://www.linkedin.com/in/ronalddehuysser/ https://www.jobrunr.io/en/ Carbon-aware job processing with JobRunr Growing from an open-source project to a company 37:36 Jan Ouwens https://www.linkedin.com/in/janouwens/ https://jqno.nl/ Reducing the cost and CO2-emissions of your application Private cloud versus cloud providers 45:14 Outro
More from Foojay.io | Friends of OpenJDK and Java Programming
Runtime reflection is a quiet tax on the JVM. It is flexible, it is everywhere, and it is easy to stop noticing it until you go looking for where your CPU is actually going. Two teams did exactly that, in completely different corners of the ecosystem, and arrived at the same answer: move the work to build time. In this episode, Dmitry Moskalyuk explains the model layer behind his Foojay article on reflection-free serialization, where JSON, XML, YAML and TOML all end up as Avro. Shai Almog explains the build-time codegen pipeline of Codename One, which aims for no reflection, no service loader and no Class.forName. We compare the two and ask whether generated code is really something to avoid. Topics include: Where Jackson's reflection cost really lives, and what Blackbird does about it Jackson versus kotlinx.serialization, and why a missing feature sent the team back to Jackson Why a UI framework bans reflection, and how that differs from the backend Is generated code bad? Lombok, Manifold and jOOQ What Records and Project Leyden change for reflection Build time cost versus runtime cost, and a single source of truth for your data model Should you still use reflection in a new project?
Foojay.io quietly moved off WordPress and onto Hugo. No more CMS login, no database, no admin panel — just Markdown and AsciiDoc files, built and deployed straight from GitHub. So is a traditional CMS still the right way to run a content site in 2026, or has static tooling caught up? In this episode, Andy Damevin and Holly Cummins from the Red Hat Quarkus team join to talk through it. Andy created code.quarkus.io and Roq, Quarkus's own Java-based static site framework; Holly led the migration of quarkus.io itself from Jekyll to Roq. We go through the real security numbers behind WordPress's plugin ecosystem, and put very different static site generators head to head: Hugo and Jekyll, the veterans, versus Roq, the newcomer. Topics include: Why WordPress core is usually fine, and the plugins are where the trouble is — over 10,000 plugin vulnerabilities found since 2025 What "recovery" means for a static site versus a CMS after a hack or defacement Jekyll, Hugo, Roq and JBake compared, and why staying in Java matters (or doesn't) How to extend Roq as a Java developer, from a small PR to writing your own plugin What an actual WordPress-to-Roq migration looks like in practice Where a CMS still earns its keep despite all of this
Episode 101 of the Foojay Podcast. JDK 27 arrives on 15 September 2026 without finalising a single new piece of language syntax. It is still worth the upgrade: object headers shrink from 64 bits to 32, which the JEP measures at 22% less heap and 8% less CPU on SPECjbb2015, and G1 becomes the default garbage collector on every machine. Both changes live inside the JVM, so an application you compiled years ago picks them up with no code change at all. Simon Ritter, Deputy CTO at Azul and Java Champion, takes us through all nine JEPs in the release, explains why a non-LTS version is still worth testing against, and makes the point that "long-term support" describes the binary you download rather than anything in OpenJDK itself. We also cover the move from quarterly to monthly security updates that started in August 2026, and then look ahead to March 2027, when Project Valhalla reaches its first preview after roughly twelve years of work. Topics include: Compact object headers by default, and what 22% less heap actually buys you in production Post-quantum key exchange in TLS 1.3, and the harvest-now-decrypt-later attack it defends against JFR redaction: keeping access tokens and passwords out of flight recordings you share Structured concurrency in its seventh preview, and why an evolving API stays in preview The Vector API's twelfth incubation, and what it is waiting for Value Objects in Java 28: a new value keyword, 179,000 lines, 1,800 files, and why it will not be final in JDK 29 Whether a Simple JSON API in the JDK will survive its previews, or go the way of string templates
Episode 100 of the Foojay Podcast. No grand plan. It just happened. To mark the milestone, Frank turned the microphone around and invited other podcasters: Adam Bien (airhacks.fm), Jennifer Reif (Breaktime Tech Talks), Kadi McKean and Steve Pool (10xInsights), and Oumaima Zerouali (JCast). Same questions for each: why did you start, what broke, and what did you learn? Along the way: why a no-prep podcast works when you have 20 years of experience, the difference between writing a blog and recording a podcast, burnout from editing, AI tools that changed someone's voice into Batman, and why a Dutch Java podcast about the human side of development got its first episode from a calendar invite that became a recording.
Your Java AI application is live in production. But have you tested whether it can be jailbroken, manipulated into revealing its system prompt, or tricked into printing content it should never output? In this episode, Iryna Dohndorf, Software Engineer at Karakun Group and creator of Tiberius, explains how to bring security testing to LLM-powered Java applications. We cover why traditional unit tests break down with non-deterministic systems, how the Scan-Fixture-Validate workflow works, what buff mutation testing is, and why even well-trained models can be cracked with something as simple as the grandmother attack. Topics include: Why LLM non-determinism breaks the classic input/output test model The Scan-Fixture-Validate principle and sharing test artifacts across teams Prompt injection, jailbreaks, and emotional manipulation attacks Buff mutation: testing linguistic surface coverage Probabilistic security contracts and multi-trial scans Fingerprinting and why your model choice should not be detectable LLM as a judge: using a second model as a guardrail Getting started with Tiberius in Spring Boot and LangChain4j Guest Iryna Dohndorf - Software Engineer at Karakun Group LinkedIn Links Article on Foojay Tiberius on GitHub Security Testing Guide Timestamps 00:00 Introduction of topic and guest 01:05 The problem Tiberius wants to solve 06:39 How "traditional" unit tests don't work for LLM integrations 10:23 Scan-Fixture-Validate principle and sharing artifacts 15:15 Using different skills, for example, the grandmother skill 17:33 Testing for required versus forbidden bias 19:35 The probes across nine attack categories used by Tiberius 20:44 Buff mutation testing 26:55 Using Tiberius in your pipelines and when to fail 29:35 Using multi-trial scans 31:14 Fingerprinting: which model you use, should not be detectable 32:55 Combining multiple models, model as a judge 34:41 Sharing JSON models to improve tests 36:05 How to get started with Tiberius in Spring and with LangChain4j 36:41 Quarkus not supported yet, plans for the future 39:07 Conclusions and a call out to everyone to become a Foojay author