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

Is your Java application actually secure, or does it just look that way? In this episode of the Foojay Podcast, Frank is joined by Steve Poole and David Welch, both from HeroDevs, to dig deep into the state of Java security in 2025 and beyond.

Steve introduces the concept of zombie dependencies: end-of-life libraries that appear safely dormant but are quietly accumulating vulnerabilities waiting to bite you. David, a co-chair of the CVE Automation Working Group, explains what a CVE actually is, how the identification and disclosure process works in practice, and why AI tools like Mythos are dramatically accelerating the pace at which new vulnerabilities are found — on both sides of the wall.

Together they cover how CVEs in the Java runtime are handled through coordinated disclosure, why Maven Central is safer than most ecosystems but not a silver bullet, and what insurance companies are starting to demand from organizations that haven't cleaned up their dependency trees. They also discuss practical steps any Java developer can take today, from generating an SBOM and running Snyk or Trivy, to adopting OpenRewrite and Renovate in your pipelines, and why vibe coding with AI tools may be quietly making your security posture worse if you are not reviewing the dependency choices being made for you.

A candid, occasionally alarming, and ultimately optimistic conversation about a problem the Java community is well-positioned to lead on.

Steve Poole

• LinkedIn
• Foojay Author profile
• Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem
• Why Java Developers Over-Trust AI Suggestions

David Welch

• LinkedIn

Content

00:00 Introduction of topics and guests
04:00 What are Zombie dependencies?
05:36 What are CVEs?
11:39 How Mythos and other AI tools are influencing the CVE reporting process
16:53 How CVEs in the Java runtime are handled
21:30 How the industry is looking at the increased security threats
30:17 Developers need to make better decisions "the first time" and use the right tools
31:42 Keep your OS, JVM, and dependencies up-to-date! Insurance companies will force you...
44:48 How "safe" is Maven Central compared to other repository systems
50:48 What you can do as a Java developer to make your apps safer
59:01 Should we be scared for the following years and be careful with vibe coding?
01:04:27 Conclusion