Project Amber - Deep Dive with the features

Discover the transformative power of Project Amber, Java's initiative to enhance developer productivity through language improvements. This deep dive explores key features like Local Variable Type Inference (var), Switch Expressions, Text Blocks, Pattern Matching for instanceof, Records, Sealed Classes, Record Patterns, instance main method and more. Each is designed to reduce boilerplate, improve code readability, and streamline Java programming. Attendees will learn how these features can be applied in real-world scenarios, making Java development more efficient and enjoyable. Join us for an insightful session on embracing Project Amber's advancements and integrating them into your Java projects for a modernized development experience.

I am presenting this session at dev2next conference. Also have a condensed version at nyjavasig.com being presented on Sept 18.

GraphQL Won't Fix Your Timeouts — Bounded Concurrency Will

Teams facing slow, timeout-prone fan-out calls often reach for GraphQL as the fix, expecting the new API layer to solve what was really a sequential-calling problem underneath. This talk walks through a real rearchitecture where switching to GraphQL alone changed nothing — the same blocking, one-at-a-time calls to an external source were still there, just hidden behind a new schema. The actual fix came from three pieces working together: a DataLoader pattern to batch and deduplicate calls, batch-size tuning found through real timeout failures, and time-boxed virtual threads to bound how hard the system could hit a source it didn't control. The final design also made a deliberate tradeoff — choosing partial responses over waiting for everything, and surfacing what timed out through GraphQL's error channel instead of silently dropping it. This session covers what actually breaks when fan-out meets scale, and the concurrency discipline that fixes it — not the API layer wrapped around it.

Catching Cache Caveats: When Your TTL Is Lying to You

Every caching conversation starts the same way: do you need a cache, and how do you implement it correctly? This talk skips that question. It starts after the cache is already live and already trusted — and shows what happens when nobody ever asks how it knows it's still right.

In most systems, TTL isn't a calculated decision but it is an assumption that got copy-pasted into a config field and never revisited. A single TTL is applied across attributes that change at completely different rates, which means it's never actually correct: too long for volatile fields, too short for stable ones. When the source of truth lives in an external system you don't control, the problem compounds, some systems expose a validity flag to tell you when data has changed, most don't, and none of them agree on the contract. The result is a cache that fails silently: it doesn't crash, it doesn't alert, it just quietly serves stale data dressed up as correct until a user notices and files a bug.

This session walks through a real caching setup built on exactly these assumptions, the failure it produces, and what it actually takes to make staleness visible instead of assumed including where "just check if it's still valid" breaks down when validation costs nearly as much as the fetch it was meant to avoid.