airhacks.fm in 3 minutes

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Sunday September 20th. Adam Bien spoke with Andy, a Quarkus and Red Hat developer based near Marseille, about an unusually creative path from programmable calculators and Facebook games to modern Java tooling, static-site generation, and AI-assisted web development. [1]

Andy’s first computing memories involved an old Macintosh and HyperCard-like castle-building software, but his first real programming came on Texas Instruments calculators. As a teenager, he and his older brother made games in TI-BASIC, including an altered version of a soda-and-ice-cream-selling game in which players managed a drug-selling business. It circulated among friends at school. The amusing story illustrated a serious point: even on limited hardware, Andy was already interested less in playing games than in inventing them.

That instinct continued with early web development and Facebook’s original game platform. Andy built viral social games in PHP and MySQL, using Facebook APIs and iframe integration. One game, based on the old “Friend for Sale” model, reframed the concept as hiring friends, with rankings, limited daily actions, advertising, and paid credits. At its peak, it attracted roughly 300,000 users and earned him around 2,000 euros a month while he was a student. He said the old Facebook API made virality almost too easy because games could send notifications to people who had not explicitly opted in. Today’s more restrictive notification rules make that style of growth far harder.

Java became Andy’s turning point. One of his early university projects visually represented network traffic across a computer lab: cars and packets moved from screen to screen, calculating paths through the network. Adam called it remarkably ambitious for a student project. Professionally, Andy began with conventional Java enterprise work—JBoss Seam, later Spring—but eventually joined Red Hat after a hiring process that emphasized building a real project rather than solving timed algorithm puzzles. He argued that creative, take-home work better reflects how many developers actually operate.

At Red Hat, Andy joined Quarkus just before its 1.0 release. He praised Quarkus for offering a coherent stack rather than forcing developers to assemble and evaluate countless separate frameworks. His work includes code.quarkus.io, the code-start system behind generated starter applications, and Quinoa, which integrates frontend builds into Quarkus development.

The centerpiece of the episode was his newer work. Quarkus Web Bundler brings web-build features—dependency management through Maven or Gradle, bundling, minification, hashed assets, Tailwind, SCSS, Svelte support, and more—without requiring developers to install Node or npm. Internally it uses lightweight, platform-specific Deno binaries and esbuild, downloaded as normal dependencies.

Andy then described Roq, spelled with a Q, a static-site generator built on Quarkus. The name comes from rocks being static. Roq can render Quarkus applications using Qute templates, crawl the pages, and export them as standalone HTML for GitHub Pages or other hosting. Qute provides compile-time checking, type safety, IDE completion, iteration, CDI access, and template errors caught during builds rather than after deployment.

Adam was especially intrigued by combining Roq with local automation: a Quarkus application could detect content changes, regenerate pages, and commit them locally through JGit—even offline. Andy confirmed Roq exposes an injectable generator that can be called programmatically in production mode. Roq also includes an editor intended to make developer-managed publishing feel more like WordPress, plus Git synchronization work.

Finally, they discussed AI. Andy sees Roq’s Model Context Protocol support as useful for iteratively designing sites with AI and browser automation, while reserving AI-generated prose more for processing than replacing human writing. His own Roq-built site, Devoured.fyi, summarizes development and AI news in a polished, mobile-friendly interface that feels dynamic while being fundamentally static. Its surprising implementation is plain vanilla JavaScript with Tailwind, local storage, and static output—an example of how far a carefully assembled Java-centered web stack can go. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time!

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Monday September 14th. Adam Bien welcomed back Gunnar Morling for a discussion that connected the famous One Billion Row Challenge with Morling’s newer project, Hardwood, a lightweight, multi-threaded Java library for reading and writing Apache Parquet files. [1]

They first revisited the challenge that became a major Java-community event. The task was deceptively simple: parse a 13-gigabyte file containing one billion weather-station measurements, then calculate the minimum, maximum, and average temperature for every station. Morling’s straightforward, idiomatic, single-threaded Java baseline took about five minutes. The winning solution completed the same work in roughly 1.5 seconds on eight cores, and around 300 milliseconds when using the full capacity of a powerful server.

The key lesson was that Java can be extremely fast, but the last degree of optimization comes at a readability cost. Morling said getting from minutes to tens of seconds could still be done with maintainable code. Reaching the top leaderboard times required memory mapping, the Foreign Function and Memory API, parallel processing, SIMD and vector operations, parsing several bytes at once, and low-level bit manipulation. That code was impressive, but not the sort of code most teams should copy into ordinary business applications. Java’s best results were broadly on par with C or Rust, because highly optimized Java ultimately produces very similar machine code.

The challenge drew roughly 160 to 170 official participants, plus many unofficial implementations in other languages, databases, and command-line tools. Its most satisfying outcome, Morling said, was not the competition itself but learning and visibility for modern Java. One participant’s exceptional low-level work reportedly helped him land a role on Oracle’s GraalVM compiler team.

Hardwood grew from related performance and data-processing concerns. Morling explained the difference between row-based formats such as CSV and columnar formats such as Parquet. With rows, an analytics job that needs only temperature values may still have to read every field in every record. Parquet organizes data by column, allowing software to retrieve only the needed data, compress it efficiently with techniques such as delta encoding, and process contiguous values efficiently with SIMD. This can be especially valuable when data lives remotely on object storage such as S3, where reading less data means less time and cost.

Morling’s argument for Hardwood is that the standard Java Parquet ecosystem is burdened by a large Hadoop-based dependency tree and traditionally single-threaded processing. Hardwood instead aims for a very small core, zero mandatory dependencies, and multi-threaded operation that uses modern multi-core machines. Optional dependencies remain sensible for specialized compression algorithms or advanced AWS authentication, but he prefers owning straightforward infrastructure code where possible.

A recurring theme was how LLMs change that tradeoff. Both speakers said AI makes it more practical to implement small, well-specified pieces of code themselves, such as AWS request signing, provided tests and official specifications validate the result. They agreed that developers should still review public APIs, architecture, and hard-to-reverse decisions rather than blindly accepting generated code.

Morling also demonstrated an unexpected modern-Java experiment: Hardwood’s Java terminal interface can be compiled with GraalVM into WebAssembly and run in a browser, locally inspecting Parquet files without uploading them to a server. The episode’s larger takeaway was that Java’s current tooling can combine low-level performance, small deployment footprints, browser delivery, and AI-assisted development more effectively than many developers assume. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [2]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Tuesday September 8th. Adam Bien spoke with Helidon developer David Kral about Helidon JSON, a compile-time JSON binding and processing library designed for high performance without reflection or runtime bytecode manipulation. [1]

Kral explained that the project began as a personal experiment and grew into a Helidon feature—a pattern Adam jokingly summarized as Helidon being “a collection of pet projects.” The goal was to support Helidon Declarative’s philosophy: generate as much infrastructure as possible during compilation, including routing, server wiring, and now JSON serializers and deserializers. Instead of discovering classes and fields through reflection at runtime, an annotation processor examines marked Java types at build time and produces ordinary Java source code. [2]

That generated-source approach was the episode’s main argument. Kral said Helidon deliberately avoids the “black magic” of hidden bytecode manipulation. Developers can inspect generated code, set breakpoints in it, and follow exactly how JSON conversion happens. Adam compared the approach with Micronaut and Quarkus, which also move work to build time, but highlighted Helidon’s distinction: it produces editable Java source rather than generated bytecode. The claim is not merely speed, but debuggability and transparency.

The discussion turned to JSON-B and JSON-P, the Jakarta standards Adam frequently uses. Helidon JSON is not itself a JSON-B implementation because existing JSON-B-style APIs are tied to reflection-oriented assumptions that would undermine Helidon’s design. Still, its binding API deliberately feels familiar: a central JSON binding object can serialize and deserialize Java objects, while separate JSON-P-like parser, generator, and dynamic-object APIs support more flexible, map-like JSON processing. [3]

Adam argued strongly that Helidon should consider an optional JSON-B bridge. His case was less about performance than portability and AI-assisted development. Standards such as Jakarta EE, MicroProfile, JSON-B, and JSON-P are well documented and stable, so LLMs generate code for them reliably. An adapter could let developers use a standard API while gaining Helidon’s faster implementation underneath. Kral agreed the idea had already been considered, including possible support for JSON-B or Jackson annotations, though he made no promises.

A practical limitation emerged around compile-time generation. User-defined records need a marker annotation, such as `@Json.Entity`, so the annotation processor knows which converters to create. Adam proposed a potentially useful shortcut: annotate `package-info.java` and automatically process all records in a package. Kral liked the idea immediately, calling it a good candidate for investigation—an example of “podcast-driven development.”

The performance results were striking, though Kral cautioned that they were internal JMH benchmarks rather than formal certification. For a simple object with strings, primitive values, and a nested object, Helidon JSON reportedly handled nearly 12,000 serialization operations per millisecond, compared with roughly 2,300 for Jackson and about 1,080 for Eclipse Yasson. Adam’s takeaway was that JSON-P remains perfectly adequate for ordinary applications that only emit JSON at the edge, but high-volume JSON workloads could see meaningful cloud-cost and energy savings from faster conversion.

They closed by discussing object pooling. Although reusing arrays might seem beneficial, Kral’s early experiments found simple allocation could be faster than a pool, especially given the desire to remain friendly to virtual threads and avoid problematic thread-local designs. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time!

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Monday August 31st. Adam Bien spoke with Java veteran Simon Ritter of Azul about what separates Azul’s free Zulu OpenJDK distribution from its commercial Azul Prime JVM, formerly known as Zing. The central theme was how to improve Java performance—especially latency, throughput, and startup—without changing or recompiling application code. [1]

They began with garbage collection, historically a major cause of unpredictable Java pauses. Simon explained Azul’s C4 collector, short for Continuous Concurrent Compacting Collector. Traditional collectors often stopped application threads while moving objects safely around the heap. Those pauses might be milliseconds, but could grow dramatically with enormous heaps. Simon recalled an extreme customer case from around a decade ago: garbage collection paused an application for a day and a half. Restarting was not a useful alternative because loading the application’s data back into memory took even longer. [2]

C4’s answer is to perform collection, including heap compaction, continuously and concurrently with application execution. It avoids the fragmentation problem faced by some non-compacting collectors. There can still be tiny pauses around JVM safe points, but Simon described them as being on the order of milliseconds rather than long stop-the-world events. The collector can support heaps up to 20 terabytes; amusingly, the current limit is essentially due to needing one additional bit in an object header to address more memory.

Adam clarified the product split: Zulu is Azul’s free, standard OpenJDK build, with the familiar HotSpot collectors such as G1 and ZGC. Azul Prime is the paid JVM offering that includes C4. Simon said ZGC was strongly inspired by published C4 work, though Prime is not simply Zulu plus one garbage collector. Its JVM also replaces HotSpot’s older C2 optimizing compiler with Azul’s Falcon compiler. [3]

Falcon is built around LLVM technology and can produce more aggressively optimized machine code. Simon cited benchmarks showing as much as 53 percent more Kafka transactions per second and roughly 30 percent more for Cassandra in some cases. He stressed that gains vary: some workloads improve by 10 to 50 percent, while a few can initially perform worse and require investigation. The practical pitch is not only faster systems, but lower cloud bills by accomplishing the same workload with fewer resources.

The other big feature is ReadyNow, which tackles Java warm-up. Normally, every JVM startup begins cold: it loads classes, profiles code, compiles it, sometimes deoptimizes incorrect assumptions, and slowly reaches steady-state performance. ReadyNow captures data from a real training run—loaded and initialized classes, profiling information, compiled methods, and prior deoptimizations—then reuses it at the next startup. Simon said an application can reach roughly 97 to 98 percent of its earlier steady-state performance by the time it reaches its main entry point. [4]

For cloud deployments, Azul can centralize profiles through Optimizer Hub and even move compilation into a Cloud Native Compiler service. That saves CPU and memory in small containers, lets multiple microservice instances reuse compiled work, and allows idle compiler capacity to produce better optimized versions for future requests.

The key takeaway was that modern JVM performance is no longer only about avoiding garbage-collection pauses. Azul’s approach combines concurrent collection, stronger JIT compilation, remembered warm-up profiles, and centralized compilation to make Java systems more predictable and potentially less expensive to operate. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [5]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Thursday August 27th. Adam Bien welcomed back Ian, a runtime and performance engineer, for a deep technical conversation about Java design decisions, garbage collection, Android’s ART runtime, and better ways to understand system performance. [1]

They began by “turning back time” to question some longstanding Java choices. Ian praised early Java APIs for being much clearer and more concise than comparable C++ or Microsoft libraries in the 1990s. But he argued that later decisions sometimes changed important performance properties without enough regard for real workloads. His main example was `String.substring`. Older Java implementations could create a cheap view into an existing character array, making substring operations effectively constant-time. Later versions copied characters into a new array, avoiding the risk that a tiny substring would keep a huge original string alive, but turning the operation into work proportional to the substring’s size. Ian said this caused serious regressions inside Google for code that relied heavily on cheap substrings. [2]

That led to a broader API-design lesson: `substring` returns `String`, not the more abstract `CharSequence`, so Java left itself less flexibility to change implementations. Ian suggested that, in hindsight, `CharSequence` might have been the better conceptual “string” type. He also noted that Java’s use of `int` for lengths limits strings and arrays to roughly two gigabytes, a pragmatic 1990s choice that now constrains structures such as ropes, which can represent very large concatenated sequences.

One of the most counterintuitive arguments concerned `StringBuilder` and `StringBuffer`. Developers are routinely taught that `StringBuilder` is always preferable because it lacks synchronization. Ian argued that this can force an expensive final array copy when `toString()` is called: without locking, the builder cannot safely hand its backing array directly to the resulting string. A synchronized `StringBuffer`, if locks are uncontended and well optimized, could theoretically avoid that copy. His wider complaint was Java’s “attack of the clones”: defensive copying becomes the only safe choice when ownership and immutability cannot be expressed clearly enough.

The episode then shifted to Ian’s own work on garbage collectors. He described helping create Azul’s C4 collector and inventing a read-barrier technique now reflected in collectors such as ZGC and Shenandoah. The surprising origin story: he worked out the key idea with pen and paper while riding a train to JavaOne, unwilling to carry a huge work laptop through a rougher part of San Francisco. The trick used XOR on memory references to determine efficiently whether objects were on the same memory page, replacing costly memory lookups with computation.

Ian also helped drive ART, Android’s replacement for Dalvik. ART’s ahead-of-time compilation, faster interface dispatch, and concurrent generational garbage collection made older Android devices dramatically smoother. He cited Google Maps improving from roughly five frames per second to around fifteen on an old Nexus 7, while garbage-collection pauses fell from about 50 milliseconds to around one millisecond. ART initially broke WhatsApp because its bytecode obfuscator generated unbalanced locks, illustrating the messy compatibility realities of replacing an operating system runtime.

Finally, Ian discussed his current Linux-kernel work on observability, especially improving the `perf` tool. His point was that developers often celebrate a benchmark improvement without proving why it happened. Better tools should expose CPU, GPU, memory, cache, and system-level behavior so performance work is based on evidence rather than stopwatch guesses. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [3]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Sunday August 23rd. Adam Bien spoke with Canadian developer Steve Hannah in a wide-ranging conversation spanning early home computers, PHP and Java history, open source CRUD tooling, AI-assisted coding, and the changing shape of development environments. [1]

Hannah’s first computer was an Apple IIGS around 1986. He remembered loading games from five-and-a-quarter-inch floppy disks, playing HardBall, and carefully keeping baseball statistics by hand. Although an uncle programmed in assembly language, Hannah did not seriously start coding until 1997, when the early web inspired him to build web pages. That led him through Perl, CGI, Flash, PHP, and eventually Java.

The discussion offered an affectionate look at the web’s more primitive era. CGI scripts received request data through environment variables, and developers often had to manually parse query strings. Adam recalled preferring Java partly because CGI scripts started a new process on every request, while Hannah explained why PHP felt dramatically easier after Perl: it removed much of the initial complexity and made it possible to build useful things quickly. Both acknowledged that PHP’s early conveniences, including globals, later became sources of bad practices and security problems. Still, Hannah argued that modern PHP has evolved into a serious enterprise language, often closer to Java than Java developers assume.

Their core comparison was cultural as much as technical. Java encouraged developers to think in classes, types, and structure; PHP made arrays, maps, and direct experimentation feel natural. Hannah’s view was that quick-and-dirty Java rapidly becomes unpleasant, pushing people toward architecture, while PHP can remain enjoyable longer—at least until a project becomes too large. Adam’s broader conclusion was that ecosystems tend to converge on the same good ideas, while frequently copying one another’s unnecessary complexity too.

Hannah described his long-running open source project, ZetaFace, originally called DataFace. It generates web-based CRUD applications from MySQL databases, inspired by the speed and usability of FileMaker. Its name changed after a Texas company called DataFace Computer Solutions sent a cease-and-desist letter over a confused support email. Rather than fight, Hannah crossed out the “D,” effectively turning DataFace into ZetaFace. The surprising detail: many internal classes still use the original name, because a wholesale PHP refactoring was not appealing at the time—though today he says Claude could likely do it.

The conversation then moved decisively into AI. While on parental leave, Hannah has been building a personal Swing-based IDE tailored to his actual workflow: many repositories, worktrees, branches, terminals, Claude Code sessions, Codex sessions, Docker tasks, and cross-repository features. He said an initial version took less than a day with AI assistance. Adam noted that Swing and JavaFX may see a small revival because LLMs understand them well and Java ships strong desktop capabilities out of the box.

Adam’s strongest argument was that Java is especially effective for LLM-assisted enterprise development. Java’s type system, standards, official APIs, Javadoc, and long public history give models reliable context and help them correct errors through compilation and tests. He recommended grounding models in official Jakarta EE and MicroProfile APIs, documenting intent rather than trivial getters and setters, using package-level documentation, and minimizing dependencies. His claim was that standards-first Java can cut AI context and inference costs substantially while reducing ambiguity.

They also touched on deploying Quarkus applications to AWS Lambda with Java-based CDK infrastructure, fast cold starts, and even inexpensive keep-warm pings. The planned discussion of Hannah’s JDeploy project was postponed, leaving a promise to return for a future episode on JDeploy, Codename One, Java desktop tools, and AI-era development workflows. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [2]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Sunday August 9th. Adam Bien spoke with Donald Raab in a nostalgic but surprisingly technical journey through early personal computers, programming languages, Smalltalk, and the long path that eventually led Raab to create Eclipse Collections. [1]

Raab’s first computer was the Epson HX-20, often described as the world’s first laptop. Released in the early 1980s, it had a tiny LCD display with only a few lines of text, built-in BASIC, a microcassette for storage, optional memory expansion, and even a miniature receipt-style printer. Raab recalled teaching himself BASIC on it as a child, writing an overtime-pay calculator and experimenting with graphics and simple game ideas. He also had an acoustic-coupler modem, the kind where a telephone handset sat in rubber cups, making the computer feel like a scene from WarGames. [2]

The conversation wandered through Atari 2600 games such as Pitfall, Montezuma’s Revenge, Ultima, Diablo, and SimCity. A particularly fun detail was Raab’s appreciation for a later Pitfall reboot that included an Easter egg: players could discover and play the original Atari 2600 game inside the newer game.

Programming, though, became the episode’s real subject. Raab moved from BASIC to Apple II-compatible machines, Pascal, FORTRAN, COBOL, Prolog, dBASE, Clipper, and later Smalltalk and Java. He said his fascination was never simply about mastering languages; it was about the ability to create things and solve problems through different computational models. dBASE was especially practical because it combined a programming environment and local database in one package, allowing useful business applications to be built without installing and integrating a separate database server.

Adam and Donald compared the older xBase world—dBASE, Clipper, FoxPro, and related tools—with modern distributed applications. Their key observation was that these old systems often felt highly productive because code and data lived locally on one machine. When organizations migrated toward client-server or distributed Java systems, they gained scalability and interoperability but could lose the immediacy and simplicity users had enjoyed in desktop database tools.

Adam shared a notable migration story: he once helped port mission-critical Clipper software to Java in only two weeks because a longtime developer still understood the embedded business logic. A later, more formal rewrite effort failed after years because the original expertise and unwritten rules were no longer available. The lesson was clear: documentation and diagrams cannot always replace people who know why a system behaves as it does.

Raab identified learning Smalltalk at IBM’s Object Technology University as the major turning point of his career. After five intense weeks of training and extensive hands-on lab work, he came to understand object-oriented programming differently. Smalltalk introduced him to rich collections, repository-based development, method-level history, and “blocks,” now more commonly called lambdas. He argued that many ideas treated as modern innovations have much older roots.

That history explains Eclipse Collections. Raab initially disliked Java because, compared with Smalltalk, it lacked expressive collection operations and lambdas. At Goldman Sachs, he faced repeated for-loops, memory constraints in 32-bit Java, and large in-memory caches. He wanted code that stated what it did—filtering, grouping, testing—rather than repeatedly exposing how it iterated. Eclipse Collections emerged from that practical need, although Java developers had to wait roughly ten years for Java 8 lambdas to make the approach truly pleasant.

They closed by promising a future episode focused on Smalltalk blocks, Java lambdas, and the origins and design of Eclipse Collections. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [3]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Monday August 3rd. Adam Bien welcomed Olympio back for a conversation that began with Java Advent and quickly widened into standards, AI code generation, Java’s role in production inference, and even water-safety IoT. [1]

Olympio first corrected Adam’s joking reference to “Java Advent 2026,” noting they were talking about the 2025 edition. He said this year’s calendar had plenty of AI content, but felt more coherent than earlier waves of hype. One article that stood out to him was Simon Martinelli’s piece on specification-driven development, which reminded him of earlier university-era promises around UML and generating systems from models. He also noticed more discussion about Java becoming relevant again as AI applications move out of proof-of-concept mode and into operational enterprise systems. [2]

That led to one of the episode’s strongest arguments: Adam pushed back against the assumption that AI automatically means Python. He distinguished experimentation, training, and notebooks from production inference. Python, he said, is convenient for academia and quick exploration, but enterprise inference often just needs an HTTP client for remote models, or a fast runtime and mature ecosystem for local models. Olympio agreed historically: Python won a lot of mindshare because academics and scientists already used it, but production demands are different. [3]

The discussion then turned into a broader defense of Java’s boring strengths. Adam argued that if a client already has Java in production and it works, it is more honest to improve that ecosystem than to chase novelty. Olympio added that Java is more than a language; it is the JVM, libraries, tooling, and compatibility. They also discussed Kotlin, but Adam’s point was that syntactic sugar is fine if you enjoy it, as long as teams do not invent fake business needs to justify switching stacks.

The most technical and perhaps most surprising section was Adam’s claim that Java is uniquely good for LLM-generated enterprise code. His reasoning was that Java’s standards, JSRs, Jakarta EE, MicroProfile, JDBC, servlets, and related APIs were publicly specified in a clean, normative way for decades. Because LLMs were trained on that material, Adam says they hallucinate less when guided toward the API and away from implementation details. He described using old BCE, or boundary-control-entity, package structures and short prompts like “create Zuica BC” to get high-quality, scalable code. He made a similar point about web components and MDN standards: standards reduce prompt size, save inference cost, and improve generated output.

Olympio then walked through Java Advent highlights: Eclipse Collections, WebAssembly, TornadoVM, Chicory, pattern matching, Quarkus, Rook, and recurring contributors like Markus Eisele. He also explained how the calendar is organized, with a small CFP and a mix of longtime contributors and new writers. One funny moment was his memory of a proposed article on “best practices in Python” for Java Advent; Adam immediately joked about whether such things exist.

The final turn was unexpectedly practical. Olympio described his current company’s IoT work around Legionella detection. Their sensors attach to pipework, measure water temperature continuously, and help identify conditions where the dangerous bacteria may grow. He explained that the risk often comes not from drinking water, but inhaling vapor during showers or washing, which can lead to severe pneumonia. Adam connected this to earlier podcast topics around industrial Java, Apache IoT projects, ASML machines, and robotics at Picnic, all examples of Java showing up far beyond classic enterprise web apps.

They closed with plans for Adam to contribute to a future Java Advent and a possible migration of the Java Advent site from WordPress and PHP to Rook on Quarkus. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [4]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Thursday July 23rd. Adam Bien spoke with Johan about Occurrent, Johan’s Java and Kotlin library for building event-sourced applications, and the discussion quickly turned into a deeper exploration of what event sourcing really means in practice. [1]

Johan explained that Occurrent began partly as a friendly challenge. A friend had built a .NET event-sourcing framework, and Johan kept suggesting simpler approaches using functions instead of many framework concepts. Eventually he decided to implement his own ideas. His goal was not a massive, opinionated framework, but a pragmatic library that could work in production, be easy to test, and let developers introduce event sourcing gradually into existing systems. [2]

A major theme was simplicity. Johan emphasized that event sourcing is often presented with complicated diagrams and terminology, but at its core it means storing events instead of overwriting current state. When new decisions are made, the application reads the previous events, derives the current state, and appends new events. Adam connected this to real project examples, including tractors sending telemetry, Kafka Streams calculating statistics in real time, and application provisioning represented as state transitions.

They spent a lot of time untangling event sourcing, CQRS, CQS, and event-driven architecture. Adam argued that separating reads and writes is often just normal engineering, not something that needs a grand label. Johan agreed on being pragmatic, but distinguished cases where read models are replicated or transformed from write models. He also noted that event-sourced systems often use subscriptions to build views from persisted events, though that is not required by event sourcing itself.

One notable debate was about querying the event store. Johan said some event-sourcing purists treat querying the event store as an anti-pattern, but he intentionally allows it in Occurrent because it can solve practical problems. For example, by using CloudEvents attributes such as subject, a system could query all events related to a user. He also described using database constraints, such as unique email constraints, to enforce certain invariants consistently.

Another important distinction came during the audit discussion. Adam mentioned audit requirements as a strong reason to preserve history. Johan pushed back gently: auditing can show that a value changed, but event sourcing captures the business reason for the change. An audit log might say an address changed from one value to another; a domain event can say the user moved, or customer service corrected the address. That “why” is the crucial difference.

The liveliest technical exchange centered on Kafka. Adam described systems where Kafka topics and streams effectively carried all domain behavior, with events enriched through pipelines and consumers subscribing as needed. Johan said that sounded like event-driven architecture, not strictly event sourcing, because event sourcing requires basing decisions on persisted event histories for a specific business object. They agreed Kafka can be extremely useful, but disagreed on whether it should be considered a classic event store.

Finally, Johan described how Occurrent works. It stores events as CloudEvents, currently with several MongoDB implementations and an in-memory option, but it does not force domain classes to depend on Occurrent annotations or base types. Developers can model domain events as Java records, sealed interfaces, or anything else, then map them to CloudEvents. The decision logic can be simple static methods: take prior events, fold them into state, make a decision, and return new events. Adam compared the idea to Redux, where state is derived from a central event flow rather than duplicated in many places.

They closed by agreeing there was much more to discuss, especially around definitions, examples, and Occurrent’s design. The episode’s big takeaway was that event sourcing is less about fashionable terminology and more about preserving meaningful business history, making decisions from that history, and choosing pragmatic tools without losing the domain intent. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [3]

Here is The Daily FM summary of the airhacks.fm podcast with adam bien that aired on Friday July 17th. Adam Bien welcomed Stan back for a wide-ranging, very practical discussion about testing, CI/CD, microservices, Quarkus, databases, and the danger of measuring the wrong things. [1]

They started playfully, with Adam joking that Stan had decided testing and CI/CD were a waste of time. Stan pushed back immediately: he has been using continuous delivery since around 2012, even working as a CI/CD engineer, and said tests are especially valuable when new people join a project and inevitably make mistakes while learning the system. [2]

Using a new Quarkus microservice as the example, they compared how each of them would begin. Stan said his first impression of Quarkus was positive, especially the fast reload and simplicity, though he was surprised by some dependencies he saw in the generated project. From there, the conversation moved into test categories. Stan distinguishes unit tests, component tests, and system tests. For him, unit tests call classes or methods directly with no framework context; component tests may load application components but avoid real HTTP; and system tests require the whole system to be deployed. Adam uses similar layers, though he often calls the middle category integration tests, partly because of Maven conventions and older definitions.

A central takeaway was that testing terminology is messy, but practical value matters more than names. Adam prefers system tests that call a deployed service over HTTP from the outside. He likes having a separate system-test module because it proves what a microservice really needs to operate, helps document the API, supports backward compatibility checks, and can be adapted for stress or performance testing. Stan prefers to test most functionality at the component level, where failures are easier to debug, and then use health checks to verify infrastructure.

The strongest argument in the episode was against code coverage as a management metric. Stan said he no longer measures coverage because people optimize for the number rather than the quality of the tests. Adam agreed and described projects with excellent coverage, lots of mocks, and green builds, but no confidence that the application actually worked. One of the most memorable examples was Adam’s story of teams invoking getters and setters through reflection just to increase coverage, even though no meaningful behavior was verified. They also discussed mutation testing, which changes business logic during tests to see whether assertions catch it. Both saw the value, but Stan noted it can be slow and expensive in effort.

They also criticized over-engineered mapping layers, especially the old obsession with DTOs, DAOs, and tools like Dozer. Stan described using PostgreSQL to generate JSON directly from queries, avoiding unnecessary transformations. Adam connected that to a broader theme: architectural fashions come and go. Stored procedures were once forbidden, NoSQL rejected SQL and transactions, and then many NoSQL systems gradually reintroduced SQL-like querying and transactions.

Finally, they compared deployment pipelines. Stan described Jenkins building Docker images, deploying to dev, running health and performance checks, and promoting to production manually. Adam described AWS-based pipelines with CDK, CodePipeline, Lambda, versioned S3 artifacts, and system tests against freshly deployed endpoints. Despite Adam expecting more disagreement, they mostly converged on the same lesson: test what gives real confidence, automate what matters, and do not let vanity metrics replace working software. Thank you for listening to airhacks.fm in 3 minutes from The Daily FM. See you next time! [3]