airhacks.fm in 3 minutes

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]