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?

Guests:
Dmitry Moskalyuk, Senior Backend Engineer
Dmitry on LinkedIn
Shai Almog, Author, DevRel and open source developer working on Codename One
Shai on LinkedIn

Links:

Dmitry's article on Foojay
Shai's article on Foojay
Jackson Blackbird
Apache Avro
Project Leyden
Full show notes with every link

Timestamps:
00:00 Introduction of topic and guests
01:50 About the new Foojay, contributing with GitHub pull requests
03:17 What is Apache Avro
04:26 What is Codename One
06:31 What is Blackbird in Jackson and compared to kotlinx mechanisms for different content parsers
10:01 Why Codename One focuses on "no reflection, no service loader, no Class.forName"
14:23 Is automatically generated code bad (Lombok, Manifold, JOOQ)?
17:47 Java evolutions that bring improvements into the system (Records, Project Leyden)
21:31 Is reflection changing through Java versions?
24:29 Build time cost versus runtime, Project Leyden
28:41 Use of reflection in UI versus backend
32:16 Benefit of your data model in a (Java) object, having one source of truth, good debugging
35:35 Should you worry about serialization in a small project
37:38 Serialization and security
38:57 Should I still use reflection/serialization in a new project?
43:22 Conclusion

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

Guests:

Andy Damevin on LinkedIn - Principal Software Engineer at Red Hat, Quarkus core team, creator of code.quarkus.io and Roq

Holly Cummins on LinkedIn - Senior Principal Software Engineer, Red Hat Quarkus team, led the quarkus.io migration from Jekyll to Roq

Links:

Migrate from WordPress to Roq
Roq
Hugo
Full show notes

Timestamps:
00:00 Introduction of topic and guests
03:29 Why WordPress is not the best choice for most sites
04:36 Difference between CMS-driven websites and static websites
07:02 Jekyll versus Roq and other systems
11:04 How to extend Roq
12:59 Moving from WordPress to Roq
14:43 Pulling data with JBang or Roq from external sources into your publication process
16:09 Why should I use Roq instead of Jekyll or Hugo?
24:33 Static websites can be created with a small team and are much cheaper (or even free) to host
26:52 How many WordPress websites have a backup to recover after getting hacked? And the advantage of having your content sources on Git.
33:04 Is there still a use case for WordPress-like systems?
37:09 Conclusions

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

Guest: Simon Ritter
Deputy CTO at Azul, Java Champion
Simon on LinkedIn
Simon on Foojay

Links:
Full show notes, with every JEP linked
JDK 27
What CSPUs Mean for Your Release Pipeline
What to Know About Garbage Collection as a Java Developer!
Project Valhalla

Timestamps:
00:00 Introduction of the topic and guest
01:27 How long Simon has been doing Java
01:54 Why release 27 is important, even when not being a Long Term Support release
04:55 Quarterly and monthly security updates between new version releases
08:07 Which JVM versions are most used in companies
09:23 JEP 534: Compact Object Headers by Default
14:51 JEP 523: Make G1 the Default Garbage Collector in All Environments
18:59 JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
22:55 JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)
25:35 JEP 536: JFR In-Process Data Redaction
28:02 JEP 531: Lazy Constants (Third Preview)
29:55 JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)
33:13 JEP 533: Structured Concurrency (Seventh Preview)
38:21 JEP 537: Vector API (Twelfth Incubator)
40:28 Looking forward to Java 28 and Project Valhalla
42:31 JEP 401: Value Objects and JEP 539: Strict Field Initialization
47:36 Can we expect this to be finalized in Java 29?
48:26 LTS releases every 1, 2, or 3 years?
49:55 JEP 541: Deprecate macOS/x64
51:53 JEP 540: Simple JSON API (Incubator)
55:30 Conclusion, what to remember from this release

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.

Guests:

• Adam Bien — airhacks.fm
• Jennifer Reif — Breaktime Tech Talks
• Kadi McKean and Steve Pool — 10xInsights
• Oumaima Zerouali — JCast

• 
  

Links:

• airhacks.fm on Spotify
• Breaktime Tech Talks on Spotify
• 10xInsights | 10xInsights on Spotify
• JCast
• Foojay Podcast #67: Writing a book. Does it make you rich and famous?
• Foojay Podcast #71: 30 Years of Java with James Gosling
• Foojay Podcast #99: Testing the Untestable: LLM Security for Java Developers with Tiberius
• Frank on JCast
• Other podcasts mentioned:
• Spring Documentary

Content:

00:00 Introduction

01:00 Adam Bien (airhacks.fm)

12:52 Jennifer Reif (Breaktime Tech Talks)

26:25 Kadi McKean and Steve Pool (10xInsights)

38:43 Quote by James Gosling

39:46 Oumaima Zerouali (JCast)

48:01 Conclusion

Hosted by Frank Delporte | foojay.io

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

WebAssembly is already running inside Java applications, but most developers just don't know it yet.

In this episode, Andrea Peruffo walks us through how WebAssembly is becoming the modern, safe alternative to JNI. Run Rust, C, and other native libraries directly on the JVM, without the crash risks, per-platform packaging headaches, or the observability blackhole that JNI creates.

From JRuby's Prism parser to SQLite and full Postgres running as pure Java bytecode, the use cases are real. And the project making it possible, Endive, under the Bytecode Alliance, is open and ready to explore.

Guest

Andrea Peruffo

• GitHub: https://github.com/andreaTP/
• LinkedIn: https://www.linkedin.com/in/andrea-peruffo-32269178/
• Bluesky: https://bsky.app/profile/andreatp.bsky.social
  

Links

• 
  A New Generation of Java Libraries: Wasm Becomes the Implementation Detail
  
• 
  Chicory on GitHub
  
• 
  Endive on GitHub
  
• 
  Endive documentation
  
• 
  Bytecode Alliance
  
• 
  OpenJDK Project Detroit

Timestamps
00:00 Introduction of topic and guests
00:56 What is WebAssembly?
03:35 Comparing the performance with JavaScript
05:45 JRuby already uses WebAssembly
09:04 JNI versus FFM API versus WebAssembly
13:58 Other Java-related tools that use WebAssembly
17:56 History of the Chicory and Endive projects to bring WebAssembly to Java
21:03 Projects of the Bytecode Alliance
22:02 The Endive project as the glue to bring WebAssembly tools to Java
23:30 Integration of the Redline compiler
28:59 Why this is the perfect solution to modernize existing Java applications
31:18 Is this approach performant?
32:24 What future changes in Java and the JVM will make this even better
35:04 How Endive can be used in AI development
37:28 What to expect in Endive
41:29 Conclusions

What if you could run 35 AWS services locally in under 25 milliseconds, using just 13 megabytes of memory, with a single Docker command and no cloud bill? That's exactly what Floci does.

In this episode, Frank Delporte talks with Hector Ventura, the creator of Floci, a free and open-source cloud emulator built with Quarkus and GraalVM native compilation. Hector walks us through why he built it when LocalStack dropped its open-source community edition, how AI tooling helped him accelerate development of new service integrations, the challenges of keeping GraalVM happy with third-party libraries, and the road ahead for Azure and GCP support.

If you're a developer who wants fast local testing, a DevOps engineer writing Terraform, or a student learning cloud without the cost, Floci is worth a look!

Guest: Hector Ventura

Foojay Author page

LinkedIn

Links

On Foojay: Introducing Floci: A High-Performance, GraalVM-Powered AWS Emulator

Floci project site

Floci on GitHub

Migrate from LocalStack

Content

00:00 Introduction of topic and guest

01:48 What is Floci?

02:15 How Floci compares to LocalStack

03:01 Why Hector started Floci

04:02 Floci emulates the cloud APIs

05:02 How additional services got integrated with AI assistance

06:31 Meaning of the name Floci

07:07 Why Quarkus and GraalVM as the starting point for Floci

09:35 How Floci starts up very fast and only uses a low amount of memory

12:18 GraalVM can be hard with some libraries or frameworks

14:02 What is needed to use Floci

14:56 The challenges to support AWS, Azure, GCP and finding contributors

20:24 Funding Floci

21:04 How data is persisted in Floci

22:37 Verifying Floci versus the "real" APIs with compatibility tests

23:56 In the future: UI for Floci

25:04 Biggest challenges while creating Floci

25:32 Functionality compared between Floci and LocalStack and migrating

28:15 Feedback from the Floci users

28:58 Long-term plans for Floci

29:59 Biggest surprises during the development of Floci

31:00 Best use-cases for Floci

32:12 In the next releases...

33:31 How to get started with Floci

35:00 Conclusion