What Doesn't Kill Your JVM Makes It Stronger: From Probabilistic Testing to Resilience Patterns
Software does not simply break — it reveals. Every fault, latency spike, and cascading failure is a signal about the assumptions baked into your design. The question is whether your system — and your test suite — is equipped to hear it.
This workshop fuses two complementary disciplines into one intensive, hands-on session:
Probabilistic Testing with Punit — the statistical tooling that lets Java teams measure, enforce, and version-control the resilience properties of non-deterministic systems: LLM integrations, ML inference, distributed services, and randomized algorithms that traditional binary pass/fail tests were never designed to handle.
Resilience Engineering for Java — the design principles, and architectural patterns that turn pressure into performance, like circuit breakers, fault injection, and TDD-driven failure handling.
The thread connecting both halves is a concrete end-to-end scenario: an AI-enriched Java application, where non-deterministic LLM calls meet production-grade resilience requirements. Participants work through the full arc — from writing probabilistic test specifications and latency percentile assertions, to implementing and verifying the resilience patterns that make those specifications pass.
Participants leave with a concrete vocabulary, a proven pattern catalogue, and running JUnit 5 tests that express and verify resilience as first-class distributional contracts, and not vague aspirations.
The problem we solve
Modern Java applications face a paradox, namely that they grow more complex while quality demands grow stricter. AI is reenforcing the problem. Teams grapple with:
• Non-deterministic behaviour in LLM integrations, distributed services, and randomized algorithms that traditional binary pass/fail tests cannot adequately verify.
• Resilience patterns that are understood conceptually but rarely measured or enforced in tests, or CI/CD pipelines.
• Incidents that recur because post-mortems produce insight but not code.
• Pressure cycles that harden individual engineers but leave the system fragile.
The solution is not more heroism. It is architecture and tooling that make fragility visible, measurable, and progressively eliminable.
Learning Objectives
By the end of this workshop, participants will be able to:
• Distinguish between fragile, robust, resilient, and antifragile system characteristics with concrete Java examples.
• Apply fault-tolerance patterns — circuit breakers, bulkheads, retries, fallbacks — to production-grade service code.
• Design for chaos: plan and execute controlled fault injection in development and staging environments.
• Write @ProbabilisticTest specifications in Punit that encode statistical success criteria — threshold, confidence level, and sample size — as verifiable JUnit 5 tests.
• Use Punit’s Explore, Optimize, and Measure modes to tune and baseline non-deterministic system behaviour.
• Assert latency at the percentile level (p50, p90, p99) rather than averages, and commit YAML spec baselines to version control as regression anchors.
• Deploy The Sentinel for continuous monitoring of stochastic behaviours in deployed environments without test framework dependencies.
• Describe distributional contracts as an extension of Design by Contract for stochastic systems, grounded in the javai-R statistical methodology.
Elevator Pitch
Why This Workshop , Why Now
The Java ecosystem is at an inflection point. LLM integrations and ML-backed services are entering production Java stacks at scale, but the tooling teams rely on — deterministic unit tests and average-latency SLAs — was not designed for stochastic systems. At the same time, increasing system complexity and tighter release cadences create pressure that fragile architectures cannot absorb.
This workshop addresses both dimensions simultaneously: it teaches engineers how to design systems that benefit from pressure (antifragility) and gives them the statistical tooling (Punit) to express and verify those properties in code. The combination of veteran resilience engineering practice and novel probabilistic testing methodology makes this workshop genuinely unique in the Java conference landscape.
Iryna Dohndorf is a software engineer at Karakun, where she works on customer projects using the Java technology stack. With strong technical expertise, genuine curiosity, and a deep passion for computer science, she develops technologies that tackle the challenges of modern companies and today’s society.
An enthusiastic interdisciplinary researcher and developer, Iryna has conducted research in modeling and optimization at TU Dortmund and has worked on software for autonomous driving, government agencies, and EU projects supporting the advancement of organic farming.
Beyond her project work, Iryna is deeply engaged in the international developer community. She is an active member of the BaselOne Program Committee and the Devoxx UK Program Committee,and a frequent speaker at international conferences. Through her talks, writing, and community
involvement, she aims to inspire developers, encourage critical thinking about emerging technologies,
and contribute to the sustainable growth of the global Java ecosystem.
Outside of work, she enjoys spending time with family and friends, and is passionate about swimming, skiing, and—most recently—cycling.
You can learn more about her software development work and research at: https://iryna-dohndorf.netlify.app
Mike Mannion is a software developer, consultant, and long-time Java practitioner with more than three decades of experience building enterprise systems. He has spoken at JavaOne in San Francisco and at many other conferences and user groups.
He is the creator of PUnit, an open-source framework for probabilistic testing in Java. His recent work focuses on a problem many teams are now encountering: once AI, LLMs, distributed systems, or other non-deterministic components enter the control flow of an application, traditional one-shot assertions are no longer enough.
Mike’s talks explore how developers can regain confidence in such systems by using statistical evidence: repeated sampling, pass-rate thresholds, confidence intervals, empirical baselines, and ongoing monitoring. His goal is to make probabilistic thinking accessible to working developers without burying them in statistical theory.