DEV Community: Ashish Sharda

The IDE Is Dead. Long Live the Agent: What Google Antigravity 2.0 Actually Means for Developers

Ashish Sharda — Sun, 24 May 2026 14:17:07 +0000

This is a submission for the Google I/O Writing Challenge

Everyone came to Google I/O 2026 expecting the consumer fireworks — Gemini Omni generating videos from text, the redesigned Gemini app, smart glasses, AI Mode in Search. And Google delivered all of it, loudly.

But buried under those headlines was the announcement that actually changes how we build software.

Google Antigravity 2.0 — and with it, Managed Agents in the Gemini API — is not a product update. It's a declaration that the IDE is no longer the unit of work. And if you're a software engineer who hasn't internalized what that means yet, this is your wake-up call.

What Actually Shipped

Let me be precise, because the marketing language around this was characteristically slippery.

Antigravity 2.0 is not a new IDE. It's a five-surface agent platform that shipped simultaneously on May 19, 2026:

Desktop App — A standalone multi-agent orchestration hub. Not a text editor with autocomplete. An environment where you spawn multiple agents in parallel, schedule background tasks, and issue voice commands.
Antigravity CLI (agy) — The same agent harness, terminal-first. One curl | bash install. Google simultaneously killed Gemini CLI with a June 18 shutdown date. That's not a pivot — that's a declaration of direction.
Antigravity SDK — Programmatic access to the underlying agent harness. Host it on your own infrastructure. Embed it inside your own products.
Managed Agents in the Gemini API — A single API call that spins up a full remote Linux environment with reasoning, tool use, code execution, and stateful persistence across sessions. No context plumbing required.
Gemini Enterprise Agent Platform — The enterprise-grade deployment path with Google Cloud privacy guarantees and centralized governance for regulated industries.

The default model powering all of this is Gemini 3.5 Flash — a model that outperforms Gemini 3.1 Pro on coding and agentic benchmarks while running four times faster than comparable frontier models.

Why This Is Bigger Than the Gemini Omni Demo

Gemini Omni is impressive. The multimodal video generation got the loudest applause. But Omni is a tool. Antigravity 2.0 is an architecture shift.

Here's the problem every serious developer has been fighting for the past two years: agentic orchestration is miserable to build from scratch. If you've ever tried to wire together LangChain, a vector store, a sandboxed code executor, session memory, and tool routing into something that doesn't fall apart in production — you know exactly what I mean.

The frameworks help. They also introduce abstraction layers that become debugging nightmares the moment something goes wrong inside a black box.

Antigravity 2.0's Managed Agents API solves the hardest parts of this directly at the infrastructure level:

The sandbox is managed for you. One API call spins up an isolated Linux environment. The agent reasons, calls tools, runs code, browses the web — inside that environment. No Docker configs. No security surface to maintain.
State persists across calls. Files and context survive turns. You don't write your own context management plumbing. This alone eliminates hundreds of lines of boilerplate from most agent implementations.
The distribution pipeline is end-to-end. AI Studio → Antigravity → Google Play. Agents can natively call Google Workspace APIs. The path from prototype to production product runs through surfaces Google already controls.

This is Google doing what Google does best: vertically integrating the entire stack and making the path-of-least-resistance also the path to production.

The Things Google Didn't Say Loudly Enough

I want to talk about the parts of this announcement that deserve more scrutiny.

The AGENTS.md Pattern

Buried in the Antigravity 2.0 documentation is a detail that I think will define agent development for the next several years:

Instead of writing complex orchestration code, you can define everything in markdown files like AGENTS.md and SKILL.md and register them as a named agent.

This is the AGENTS.md pattern going first-class. If you've been following the cursor/Copilot space, you know that configuration-as-markdown for agent behavior has been bubbling up as a community convention. Google just made it an official primitive in their platform.

That's a big deal. It means agent behavior becomes auditable, version-controllable, and readable by non-engineers. For any team trying to build internal tooling with agents, this reduces the blast radius of a bad agent dramatically.

WebMCP: The Standard Nobody Is Talking About

Google proposed WebMCP, an open web standard for exposing JavaScript functions and HTML forms as structured tools to browser-based agents. It's in early preview, and the coverage has been minimal.

But think about the trajectory here: if WebMCP gains adoption, every web application becomes a potential tool surface for agents. You don't build a custom integration — you expose your existing interface through a standard protocol and agents discover it.

That's not a small thing. That's potentially the browser equivalent of what REST did for APIs.

The Pricing Reality Check

The full capability set requires the new AI Ultra tier at $100/month. Managed Agents bills per run, not per token — which means long-running agents get expensive fast.

Google is offering a $100 bonus credit buffer through May 25, 2026 (tomorrow, as of this writing), but individual developers and startups need to think carefully about the unit economics before going all-in on Managed Agents for production workloads. Cache aggressively. Mock expensive runs during development. Be deliberate about when an agent needs the full managed sandbox versus a lighter-weight tool-call loop.

The Mental Model Shift

Here's the frame I'd offer for thinking about what just happened:

For the last decade, the IDE was the unit of developer work. Your editor was your context. Your plugins were your tools. Your workflow started and ended in that window.

Antigravity 2.0 argues that the agent is the unit of work. Your agents have context. Your skills (markdown files) are your tools. Your workflow is a mesh of coordinating agents that reason, execute, and persist state across sessions.

The IDE doesn't disappear — but it becomes one surface among many, not the center of gravity.

This is the agentic era in practice, not just in marketing copy. And for engineers who build platforms, infrastructure, or developer tooling, the Managed Agents API represents the most production-ready on-ramp to that era that any major cloud provider has shipped.

What I'd Do First

If I were spinning up a new project tomorrow:

Install the agy CLI and run through a basic agent harness locally. Get the mental model from the terminal up, not the GUI down.
Read the Antigravity AGENTS.md spec carefully. This is going to be a pattern that outlasts the 2.0 release cycle.
Try a Managed Agent API call that does something stateful — have it execute code, read a file in the sandbox, and pick up where it left off on the next call. Understanding state persistence hands-on is worth more than any documentation.
Look at WebMCP. It's early, but understanding the proposed standard now means you're positioned to expose your interfaces correctly before the ecosystem converges on conventions.

Final Take

Google I/O 2026 was genuinely impressive across the board. But the most important thing for developers — the thing that will still matter in five years — isn't the Gemini Omni video demos or the redesigned app interface.

It's the fact that Google just shipped a production-grade infrastructure abstraction for agentic workflows, integrated it into a platform from prototype to Play Store, and quietly deprecated the tool that defined a generation of AI-assisted development (RIP Gemini CLI, you were fine).

The IDE is no longer the center. The agent is.

Adjust your mental model accordingly.

I Work in Drone Traffic Management. Here's What Gemma 4 Changed.

Ashish Sharda — Sun, 24 May 2026 14:02:59 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

Every morning before I open Slack, I think about airspace.

Not metaphorically. I'm the Head of Engineering at a drone UTM (Unmanned Traffic Management) platform — software that keeps drones from colliding with each other and with manned aircraft over cities where large-scale commercial drone operators and FAA-regulated fleets are flying missions. Our system processes flight plans, validates airspace conflicts in real time, and communicates with the FAA's DroneZone infrastructure.

Airspace is genuinely complex. A single flight corridor over a city involves Class B shelves, TFRs that pop up with 20 minutes of notice, active NOTAMs, LAANC grid authorizations, and dynamic separation rules that change based on weather and traffic density.

Then Gemma 4 dropped on April 2nd, 2026, and I started rethinking some assumptions.

What I Actually Needed (And Why Previous Models Fell Short)

The pain point isn't data — we have plenty of that. It's translation. Drone operators range from ex-military pilots who know the FARs cold, to delivery companies that just hired someone last week to run a drone route. The same airspace data needs to be communicated completely differently to each audience.

NOTAMs (Notices to Air Missions) are a perfect example. They look like this:
!PHX 05/014 PHX NAV ILS RWY 8 LOC UNUSABLE 140DEG CW 220DEG BEYOND 18NM
BLW 4000FT MSL 2605161400-2605171400

For a Part 107 certified pilot, that's readable. For a logistics coordinator managing 40 simultaneous drone deliveries, that's a 500ms context-switch that shouldn't be their problem.

I'd tried using LLMs for this translation layer before. The issues were consistent:

Hallucination on technical specifics: Models would confidently describe restrictions that didn't exist, or miss ones that did
No reasoning about implications: Summarizing the NOTAM is one thing; telling the operator "this means your planned corridor at 350ft AGL through this zone is blocked from 2pm to 4pm" requires multi-step spatial reasoning
Context window constraints: A real airspace brief for a complex metro area involves dozens of NOTAMs, the full Part 107 ruleset, current TFR data, and the specific flight plan. Earlier models hit walls fast
Size vs. capability tradeoff: Running a 70B model locally on field hardware wasn't viable. The lighter models weren't smart enough.

Gemma 4 changes this calculus in specific, measurable ways.

The Model I Chose and Why It's the Right Tool

I'm using the Gemma 4 26B MoE (Mixture-of-Experts) variant, and the choice was deliberate.

The 26B MoE activates only ~4 billion parameters per inference pass — meaning it has the intelligence of a much larger model at a fraction of the compute cost. On a single RTX 4090 (24GB VRAM), it runs comfortably at full precision. For an application that needs to serve dozens of operators simultaneously with sub-3-second response times, this matters enormously.

Here's the tradeoff table I worked through:

Model	Why I considered it	Why I didn't pick it
Gemma 4 E4B	Runs on mobile / edge hardware	Not enough reasoning depth for multi-NOTAM conflict detection
Gemma 4 31B Dense	Maximum capability, 256K context	20GB+ VRAM, overkill for most queries
Gemma 4 26B MoE	Near-31B quality, 12GB VRAM, 256K context	— This is the one

The 256K context window on the MoE is the other unlock. I can now dump an entire airspace brief — full NOTAM batch, the relevant CFR sections, the operator's specific flight plan, their certification history — into a single prompt and get coherent, cross-referenced reasoning back. No chunking, no retrieval gymnastics, no lost context.

And then there's the benchmark that actually made me sit up: 86.4% on τ2-bench Retail (multi-step agentic tool use). Up from 6.6% on Gemma 3. That's not an incremental improvement. That's a model that can now actually do things in a multi-step workflow, not just describe what should be done.

What I Built: SkyBrief

I built a tool called SkyBrief — a Gemma 4-powered airspace intelligence assistant for drone operators.

🔗 Live app: https://skybrief-nine.vercel.app
🔗 GitHub: https://github.com/ashishjsharda/skybrief

The workflow:

Operator drops in a NOTAM (PDF, text, or image of a sectional chart)
Or types a natural language query: "I need to fly at 400ft AGL over downtown Phoenix tomorrow at 10am — what do I need?"
Gemma 4 26B MoE processes it with a system prompt encoding FAA Part 107 rules, airspace classification knowledge, and LAANC requirements
Returns a structured response: plain-English summary, specific conflicts identified, and an operator-ready compliance checklist

The key architectural decision: Gemma 4 does the reasoning, not the retrieval. We keep a separate data layer for live NOTAM feeds and TFR data. Gemma's job is to take that data and turn it into something a human operator can act on in under 10 seconds.

The thinking mode is not a gimmick here. For complex multi-NOTAM scenarios, watching the model reason step-by-step through airspace geometry produces outputs that are verifiably correct in ways that single-pass models can't match.

The Shift That Actually Matters

Here's the thing I keep coming back to.

We've built an enormous amount of programmatic logic to parse airspace rules and flag conflicts. That logic is valuable — it's precise, auditable, and fast. But it's also brittle. New airspace designations, new waiver categories, new operator certification types — every change requires engineering cycles to handle.

What Gemma 4 represents is a system that understands the underlying regulatory intent, not just the current ruleset. When I prompt it with a scenario that doesn't fit neatly into our existing rule categories, it reasons through it from first principles.

The Apache 2.0 license matters here too. In aviation and airspace management, you cannot run mission-critical reasoning through an external API with opaque terms of service. The ability to deploy Gemma 4 on-premises, air-gapped if necessary, with full control over the model weights, is not a nice-to-have. It's table stakes.

Honest Limitations

Gemma 4 still hallucinates on specifics. NOTAM coordinates, frequency values, altitude limits — anything that requires exact numerical precision should be validated against ground truth data, not trusted from model output alone.

The 26B MoE still needs real hardware. An RTX 4090 or equivalent isn't cheap. For edge deployment or mobile scenarios, the E4B is a better choice — but you'll trade reasoning depth.

Thinking mode adds latency. For use cases where operators need answers in under two seconds, gate thinking mode based on query complexity signals.

What Local AI Actually Means for High-Stakes Domains

The drone industry is a useful lens because the stakes are concrete. A bad airspace brief doesn't just inconvenience someone — it creates collision risk.

Gemma 4 running locally changes what's possible. Not in a "LLMs can solve everything" way. But in a specific, bounded way: the gap between what rule-based systems can handle and what a human expert would reason through is meaningfully narrowed by a 26B model that fits on hardware we actually own.

That gap is where the interesting engineering work lives right now.

If you're building in aviation, healthcare, legal, defense, or any domain where data sovereignty and auditability aren't optional — this is the moment to start taking local inference seriously.

I built SkyBrief in an evening session. The harder work is integrating it thoughtfully into systems where the outputs matter. That's the engineering problem worth spending time on.

Ashish is Head of Engineering in the drone UTM space and an O'Reilly author and LinkedIn Learning instructor. Find him on DEV and Medium.

SkyBrief: I Built a Drone Airspace Intelligence Tool with Gemma 4 26B MoE

Ashish Sharda — Sun, 24 May 2026 13:27:38 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

SkyBrief is an AI-powered drone airspace intelligence assistant built with Gemma 4 26B MoE. Drop in a NOTAM, airspace map, or type a plain-English query — Gemma 4 reasons over it and returns a structured brief with conflict detection and a compliance checklist.

The problem it solves: NOTAMs (Notices to Air Missions) look like this:

!PHX 05/014 PHX NAV ILS RWY 8 LOC UNUSABLE 140DEG CW 220DEG BEYOND 18NM
BLW 4000FT MSL 2605161400-2605171400

A Part 107 pilot can parse that. A logistics coordinator managing 40 drone deliveries cannot. SkyBrief uses Gemma 4's reasoning to translate complex airspace data into plain-English operator briefs — with specific conflicts flagged and a ready-to-use compliance checklist.

Demo

🔗 Live app: https://skybrief-nine.vercel.app

Try these queries to see all three status states:

🟢 CLEAR:

I want to fly a drone in a rural area, Class G airspace, 200ft AGL, no airports within 10 miles, clear weather, daytime. Part 107 certified pilot. Is this flight legal?

🟡 CAUTION:

I need to fly at 350ft AGL, 4 miles from a Class D airport, winds 15kt gusting 22kt, daytime, Part 107 certified. What do I need to proceed?

🔴 RESTRICTED:

I want to fly over a stadium during a live NFL game, 500ft AGL, no waiver, downtown Chicago near O'Hare Class B airspace. What are my restrictions?

Code

🔗 GitHub: https://github.com/ashishjsharda/skybrief

Tech Stack:

Model: Gemma 4 26B MoE via OpenRouter (free tier)
Backend: Vercel Edge Functions — API key stays server-side, never exposed
Frontend: Vanilla HTML/CSS/JS — zero dependencies, zero build step
License: Apache 2.0

How I Used Gemma 4

I chose Gemma 4 26B MoE specifically — and the choice was deliberate:

Model	Why I considered it	Why I didn't pick it
Gemma 4 E4B	Runs on mobile / edge hardware	Not enough reasoning depth for multi-NOTAM conflict detection
Gemma 4 31B Dense	Maximum capability, 256K context	20GB+ VRAM, overkill for most queries
Gemma 4 26B MoE	Near-31B quality, 12GB VRAM, 256K context	— This is the one

Why MoE wins for this use case:

Only ~4B parameters active per inference — near-31B reasoning at a fraction of compute
256K context window fits entire NOTAM batches in one prompt — no chunking, no lost context
86.4% on agentic tool-use benchmarks (up from 6.6% on Gemma 3) — handles multi-constraint airspace reasoning
Apache 2.0 — can be deployed on-premises, air-gapped for aviation compliance environments where external APIs aren't allowed

How Gemma 4 powers SkyBrief:

Operator types a query or uploads a NOTAM/airspace map
Vercel Edge Function sends it to Gemma 4 26B MoE with a FAA Part 107 system prompt
Gemma reasons through airspace rules, identifies conflicts, generates checklist
Returns structured JSON: status (CLEAR/CAUTION/RESTRICTED), summary, conflicts, checklist

Gemma 4's thinking mode is the key unlock here. For complex multi-NOTAM scenarios, it reasons step-by-step through airspace geometry — producing verifiably correct outputs that single-pass models couldn't match. Previous models hallucinated on technical specifics or lacked reasoning depth for multi-constraint airspace scenarios. Gemma 4 26B MoE solved both.

7 Things Java Devs Still Get Wrong in 2026 (Java 25/26 Edition)

Ashish Sharda — Sun, 17 May 2026 12:03:04 +0000

Java 25 is the new LTS. Java 26 just dropped. Are you still writing Java 8?

Java has changed more in the last four years than in the previous decade. Records, sealed classes, pattern matching, virtual threads, scoped values, structured concurrency — the language is practically unrecognizable from Java 8. And yet, the codebase you're shipping today? Probably still full of habits from 2015.

Here are 7 things devs consistently get wrong when writing modern Java — and what to do instead.

1. Using `Optional` as a return type... everywhere

Optional was a great idea. It's also one of the most abused APIs in modern Java.

What devs do:

public Optional<String> getUserName(long id) {
    return Optional.ofNullable(db.findUser(id))
                   .map(User::getName);
}

Then they chain .get() on it anyway:

String name = getUserName(123).get(); // ← defeats the entire purpose

Or worse, they use Optional as a field type, a method parameter, or inside a collection — all of which the Optional Javadoc explicitly warns against.

What to do instead:

Optional belongs at the boundary — as a return type when absence is meaningful and you want to force the caller to handle it.

// Good — forces the caller to handle absence
getUserName(id).ifPresentOrElse(
    name -> render(name),
    () -> render("Anonymous")
);

If you're writing isPresent() followed by get(), you've completely bypassed the point.

2. Ignoring Records for simple data carriers

How many DTOs and POJOs in your codebase look like this?

public class UserDTO {
    private final String name;
    private final String email;

    public UserDTO(String name, String email) {
        this.name = name;
        this.email = email;
    }

    public String getName() { return name; }
    public String getEmail() { return email; }

    @Override public boolean equals(Object o) { ... }
    @Override public int hashCode() { ... }
    @Override public String toString() { ... }
}

That's ~30 lines. Here it is as a Record (finalized in Java 16, standard since Java 21+):

public record UserDTO(String name, String email) {}

Done. Immutable. Has equals, hashCode, toString, and accessor methods — all generated. It also signals intent: this is a data carrier, not a service object.

In 2026, if you're not using Records for your DTOs, you're writing boilerplate the compiler already knows how to write for you.

3. Writing `instanceof` checks like it's 2010

Before Java 16, pattern matching for instanceof didn't exist. That excuse expired four years ago.

Old way:

if (shape instanceof Circle) {
    Circle c = (Circle) shape;
    return Math.PI * c.radius() * c.radius();
}

Modern Java:

if (shape instanceof Circle c) {
    return Math.PI * c.radius() * c.radius();
}

And with Java 25/26, pattern matching now extends to all primitive types too (JEP 530, fourth preview in Java 26). You can match on int, long, double directly in switch expressions:

double result = switch (value) {
    case int i    -> i * 2.0;
    case double d -> d * 1.5;
    case String s -> Double.parseDouble(s);
};

Combine sealed classes with switch expressions and the compiler enforces exhaustiveness at compile time. Add a new subclass and forget to handle it? Won't compile. That's the kind of safety you used to need a framework for.

4. Using `ThreadLocal` in a world that has `ScopedValues`

This one costs you in subtle ways that only surface under load.

ThreadLocal has been the go-to for passing context (user sessions, request IDs, tracing info) down a call stack for 20+ years. The problem: its lifetime is unclear, it leaks in thread pools, and it's hazardous with virtual threads.

Java 25 finalized ScopedValue (JEP 487) — a proper replacement:

// Old: ThreadLocal — mutable, leaks, unclear lifetime
private static final ThreadLocal<User> CURRENT_USER = new ThreadLocal<>();
CURRENT_USER.set(user);
processRequest();
CURRENT_USER.remove(); // easy to forget

// New: ScopedValue — immutable, bounded, safe with virtual threads
private static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();

ScopedValue.where(CURRENT_USER, user).run(() -> processRequest());
// automatically cleaned up when the lambda exits

ScopedValue is immutable within its scope, its lifetime is strictly bounded by the runtime, and it composes cleanly with structured concurrency and virtual threads. If you're still reaching for ThreadLocal in new code in 2026, stop.

5. Spawning platform threads for everything concurrent

This one's a performance trap that's hard to see until you're at scale.

Classic pattern: you have 10,000 concurrent HTTP requests on a ThreadPoolExecutor. Each platform thread = ~1MB of memory. At 10K concurrent requests you're looking at ~10GB of heap just for threads, and throughput flatlines.

Virtual threads (finalized Java 21, now standard) change the equation:

// Old: fixed-size thread pool, expensive context switches
ExecutorService executor = Executors.newFixedThreadPool(200);

// New: virtual threads — JVM manages scheduling
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

Virtual threads are cheap. Millions of them on a modest machine. You write normal blocking code; the JVM handles cooperative scheduling. No callback hell, no reactive chains, no .flatMap() soup.

The 2026 add-on: pair virtual threads with Structured Concurrency (still in preview as of Java 26, JEP 525). It makes concurrent subtasks feel like sequential code and guarantees clean shutdown:

try (var scope = StructuredTaskScope.open()) {
    var user  = scope.fork(() -> fetchUser(id));
    var order = scope.fork(() -> fetchOrder(id));
    scope.join();

    return new Dashboard(user.get(), order.get());
}

If one subtask fails, the scope cancels the others automatically. No manual Future wrangling.

The caveat: virtual threads shine on I/O-bound workloads. CPU-bound tasks still benefit from platform threads. If you're using synchronized blocks heavily, use ReentrantLock instead to avoid pinning.

6. Skipping `SequencedCollection` for first/last element access

This one flies under the radar. Java 21 introduced SequencedCollection, SequencedSet, and SequencedMap — interfaces that unify first/last element access across collection types. It's been standard for two LTS releases and devs still aren't using it.

Before this, getting the last element of a list was embarrassing:

list.get(list.size() - 1);       // verbose, brittle
((LinkedList<T>) list).getLast(); // only works if you know the concrete type

Now:

list.getFirst();   // works on any SequencedCollection
list.getLast();
list.reversed();   // returns a reversed view, no copying

Clean, safe, no index math. Update your collection-handling code.

7. Treating `Stream` as a one-size-fits-all tool

Streams are elegant. They're also overused to the point where devs write convoluted pipelines for things a simple for loop would express more clearly.

This is fine:

List<String> names = users.stream()
    .filter(u -> u.getAge() > 18)
    .sorted(Comparator.comparing(User::getName))
    .map(User::getName)
    .toList(); // .toList() is cleaner than .collect(Collectors.toList()) — use it

This is too much:

Optional<Integer> total = IntStream.range(0, list.size())
    .filter(i -> list.get(i).isActive())
    .mapToObj(i -> list.get(i).getValue())
    .reduce(Integer::sum);

When this is clearer:

int total = 0;
for (var item : list) {
    if (item.isActive()) total += item.getValue();
}

Streams are ideal for: transforming and filtering collections declaratively, parallel processing with parallelStream(), and composing pipelines that read naturally. They're not ideal for: stateful operations, index-aware iteration, or anything where a for loop communicates intent more clearly.

Also: stop writing .collect(Collectors.toList()). It's been .toList() since Java 16.

The Bottom Line

Java 25 is the LTS you should be targeting in 2026. Java 26 dropped March 17th with more pattern matching improvements, lazy constants, and Valhalla value classes inching toward production. The ecosystem has moved.

Here's the migration priority list:

Old habit	Modern replacement	Since
Boilerplate DTO	`record`	Java 16
`instanceof` cast	Pattern matching	Java 16
`ThreadLocal`	`ScopedValue`	Java 25 (final)
Thread pool for I/O	Virtual threads	Java 21 (final)
Manual futures	Structured Concurrency	Java 25 (preview)
Index math on collections	`SequencedCollection`	Java 21
`.collect(Collectors.toList())`	`.toList()`	Java 16

The fastest path to cleaner Java in 2026 isn't a new framework. It's actually using what the language already ships.

What's the Java 25/26 feature that's changed your code the most? Drop it in the comments — genuinely curious what the community is shipping.

Follow me for more on modern Java, Rust, and building production AI systems on the JVM.

Tags: #java #programming #webdev #todayilearned

I Built an AI Agent in Java (No Python. No Hype. Just Code.)

Ashish Sharda — Sun, 03 May 2026 11:35:15 +0000

Everyone told me I needed Python for AI. I didn't listen. Here's what happened.

Let me be real with you.

Every time I say "I'm building an AI agent," people assume I'm wrist-deep in Python virtual environments, pip dependencies, and a LangChain tutorial from 2023. And when I say "in Java?" — I get the look. You know the one.

So I built it anyway.

A fully functional AI agent. With tool use. With RAG. With MCP. Running on the JVM. Spring Boot 3.5, zero Python sidecars, no regrets.

Here's exactly how I did it — with real code you can run today.

Why Java for AI? (The Short Version)

The honest answer: because that's where my backend already lives.

Python is great for training models. But if your production system is Java — and for most of us in enterprise land, it is — then integrating AI means either maintaining a Python sidecar service, doing HTTP hops between runtimes, or just... not doing it cleanly.

Spring AI changes that equation completely. As of Spring AI 1.1.5 (released April 27, 2026 — yes, last week), you get:

A ChatClient that works with 20+ AI model providers (OpenAI including GPT-5, Anthropic Claude, Ollama, Google Gemini, Azure OpenAI, and more)
A full Advisors API for RAG and conversation memory
Native MCP (Model Context Protocol) support — servers and clients, annotation-driven
Prompt caching for Anthropic and AWS Bedrock (up to 90% cost reduction)
Switching AI providers = one line in application.yml

💡 Heads up for the curious: Spring AI 2.0 is in active milestone with GA targeting late May 2026. It moves to a Spring Boot 4.0 baseline and adds full null-safety via JSpecify. The 1.1.x line is stable and production-ready right now — that's what we're using here.

Let's build something real.

What We're Building

A Research Agent that can:

Accept a natural language question from an HTTP endpoint
Search a knowledge base (RAG) for relevant context
Call external tools via MCP (a news search tool)
Return a grounded, intelligent answer

No LangChain. No Python. Just Java 21 + Spring Boot 3.5 + Spring AI 1.1.5.

Project Setup

Dependencies (pom.xml)

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.ai</groupId>
      <artifactId>spring-ai-bom</artifactId>
      <version>1.1.5</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <!-- Spring Boot Web -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>

  <!-- Spring AI - Anthropic Claude -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-anthropic</artifactId>
  </dependency>

  <!-- Spring AI - MCP Client -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-client</artifactId>
  </dependency>

  <!-- Spring AI - Vector Store (in-memory for this demo) -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-vector-store-simple</artifactId>
  </dependency>
</dependencies>

💡 Swap spring-ai-starter-model-anthropic for spring-ai-starter-model-openai and change one config line. The ChatClient code stays identical. That's the point.

Step 1 — Configure the Model and MCP

# application.yml
spring:
  ai:
    anthropic:
      api-key: ${ANTHROPIC_API_KEY}
      chat:
        options:
          model: claude-sonnet-4-20250514
    mcp:
      client:
        name: research-agent-client
        version: 1.0.0
        tool-callbacks-enabled: true
        streamable:
          http:
            connections:
              news-server:
                url: http://localhost:8090  # Our MCP tool server (built below)

That's it for config. Spring Boot auto-configuration handles the rest.

Step 2 — Build the MCP Tool Server

This is the agent's "hands." A separate Spring Boot app that exposes tools the AI can call.

@SpringBootApplication
public class NewsToolServer {
    public static void main(String[] args) {
        SpringApplication.run(NewsToolServer.class, args);
    }
}

@Service
public class NewsSearchTool {

    @Tool(description = "Search for recent news articles on a given topic. " +
                         "Returns a list of relevant headlines and summaries.")
    public List<NewsResult> searchNews(
            @ToolParam(description = "The topic or keyword to search for") String topic,
            @ToolParam(description = "Max number of results to return") int maxResults) {

        // In production: call a real news API (NewsAPI, Bing, etc.)
        // For this demo, we return simulated results
        return List.of(
            new NewsResult(
                "Java Sees Surge in AI Workloads in 2026",
                "Enterprise teams are increasingly choosing Java for AI production systems..."
            ),
            new NewsResult(
                "Spring AI 1.1.5 Ships with Security Fixes and OpenAI SDK Integration",
                "JVM developers can now build AI agents without Python sidecars..."
            )
        ).stream().limit(maxResults).toList();
    }
}

public record NewsResult(String headline, String summary) {}

# application.yml for the tool server
server:
  port: 8090
spring:
  ai:
    mcp:
      server:
        name: news-server
        version: 1.0.0

Spring Boot auto-configuration discovers the @Tool annotation and registers searchNews as an MCP-exposed tool over Streamable HTTP. Zero boilerplate registration. Annotate a method, you're done.

Step 3 — Wire the Agent (The Good Part)

Back in our main application. This is where it all comes together.

@Configuration
public class AgentConfig {

    @Bean
    public ChatClient researchAgent(
            ChatClient.Builder builder,
            ToolCallbackProvider mcpTools,
            VectorStore vectorStore) {

        return builder
            // Give the agent access to MCP tools (news search, etc.)
            .defaultToolCallbacks(mcpTools)
            // RAG advisor — searches vector store before every prompt
            .defaultAdvisors(
                new QuestionAnswerAdvisor(vectorStore),
                new MessageChatMemoryAdvisor(new InMemoryChatMemory())
            )
            // System prompt defines agent behavior
            .defaultSystem("""
                You are a research assistant with access to real-time news tools
                and a curated knowledge base. Always cite your sources.
                When answering questions, first check your knowledge base,
                then use available tools to find current information.
                Be concise, accurate, and honest about what you don't know.
                """)
            .build();
    }
}

The ToolCallbackProvider is the key abstraction here. Spring AI auto-populates it with every tool discovered from connected MCP servers, sends the tool schemas to the LLM with the initial prompt, executes tool calls when the model decides it needs them, and feeds results back — all transparently.

Step 4 — The REST Endpoint

@RestController
@RequestMapping("/agent")
public class ResearchAgentController {

    private final ChatClient researchAgent;

    public ResearchAgentController(ChatClient researchAgent) {
        this.researchAgent = researchAgent;
    }

    @GetMapping("/ask")
    public AgentResponse ask(@RequestParam String question,
                             @RequestParam(defaultValue = "session-1") String sessionId) {

        String answer = researchAgent.prompt()
            .user(question)
            .advisors(advisor -> advisor.param(
                MessageChatMemoryAdvisor.CHAT_MEMORY_CONVERSATION_ID_KEY, sessionId))
            .call()
            .content();

        return new AgentResponse(question, answer);
    }

    // Seed the knowledge base
    @PostMapping("/knowledge")
    public void addKnowledge(@RequestBody KnowledgeRequest req,
                             VectorStore vectorStore) {
        vectorStore.add(List.of(
            new Document(req.content(), Map.of("source", req.source()))
        ));
    }

    public record AgentResponse(String question, String answer) {}
    public record KnowledgeRequest(String content, String source) {}
}

Let's See It Work

Start the news tool server on port 8090, then the main agent on port 8080.

Seed some knowledge:

curl -X POST http://localhost:8080/agent/knowledge \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Spring AI 1.1.5 supports 20+ AI model providers including OpenAI with GPT-5, Anthropic Claude, Google Gemini, Ollama, and Azure OpenAI. It provides a unified ChatClient API.",
    "source": "Spring AI release notes"
  }'

Ask the agent:

curl "http://localhost:8080/agent/ask?question=What+AI+models+does+Spring+AI+support+and+what+is+happening+with+Java+AI+adoption?"

What happens under the hood:

QuestionAnswerAdvisor searches the vector store and injects relevant context
The model sees the question + retrieved docs
The model decides it wants current news → calls searchNews("Java AI adoption", 3) via MCP
Spring AI executes the tool call, feeds results back to the model
The model synthesizes a final grounded answer
MessageChatMemoryAdvisor stores this exchange for the next turn in the session

All of that — tool use, RAG, memory — in a single .prompt().user().call().content() chain.

The Part That Gets Me

Here's the full ChatClient call:

String answer = researchAgent.prompt()
    .user(question)
    .call()
    .content();

Three lines. The advisors and tool routing handle everything else.

Compare this to the equivalent Python + LangChain setup: agent chains, callback handlers, tool registrations, memory buffer classes, and a requirements.txt that breaks every two months.

Switching AI Providers

Want to swap Claude for GPT-4o? Two changes:

pom.xml: Replace spring-ai-starter-model-anthropic with spring-ai-starter-model-openai

application.yml:

spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}
      chat:
        options:
          model: gpt-4o

Your ChatClient code? Unchanged. Not a single line.

Want to run locally with zero API costs? Swap in Ollama:

spring:
  ai:
    ollama:
      chat:
        options:
          model: llama3.2

Same code. Different model. That's the portable API promise, and it actually delivers.

What This Unlocks

Once you're here, the next steps are straightforward:

Multi-agent systems — wire multiple ChatClient beans with different system prompts and tool sets, let them coordinate via MCP
Streaming responses — swap .call().content() for .stream().content() and pipe to an SSE endpoint
Prompt caching — Spring AI 1.1.5 ships Anthropic prompt caching support out of the box, cutting costs up to 90% for repeated context
Production observability — native Micrometer integration gives you token counts, latency, and model call traces
GraalVM native — compile the whole agent to a native binary for sub-100ms startup
Spring AI 2.0 — if you're starting fresh and don't mind milestones, 2.0 adds Spring Boot 4.0 baseline, full JSpecify null-safety, and Jackson 3. GA is targeted for late May 2026.

The Takeaway

Python is great for training models. For building AI agents on top of them — integrating with your existing infrastructure, your databases, your APIs, your Spring services — Java is not second class anymore.

Spring AI 1.1.5 isn't a wrapper around Python tooling. It's a native, production-grade AI framework built for the JVM by the same team that built Spring Boot. The ChatClient API is clean. The MCP integration is real. The Advisors chain is genuinely powerful.

You don't need a Python sidecar. You don't need to learn LangChain. You don't need to maintain two runtimes.

You just need Spring Boot and an API key.

Built with Spring Boot 3.5, Spring AI 1.1.5, Java 21, Claude Sonnet via Anthropic API. Published May 2026.

Drop a comment if you want a Part 2 — streaming responses, multi-agent coordination, or GraalVM native compilation.

Spring Boot 4.0 Is Here — And It's a Big Deal 🍃

Ashish Sharda — Sun, 26 Apr 2026 14:33:14 +0000

Spring Boot 4.0 is the biggest release since the 3.0 jakarta migration. Virtual threads are now the default. GraalVM AOT is first-class. The modular starter redesign cleans up years of dependency bloat. Spring Framework 7 brings built-in API versioning. If you're still on 3.x, your migration window is closing.

What Version Are We Even On?

As of April 2026, Spring Boot 4.0.6 is the current stable release, and 4.1.0-RC1 just dropped on the Spring blog. Spring Boot 3.5 — the last 3.x line — loses open-source support on June 30, 2026, so the upgrade train is no longer optional.

The version ladder that matters right now:

Release	Status	Support Until
Spring Boot 4.0.6	✅ Current stable	Dec 31, 2026
Spring Boot 4.1.0-RC1	🔬 Release candidate	—
Spring Boot 3.5.x	⚠️ Maintenance only	Jun 30, 2026
Spring Boot 3.4.x	❌ EOL	Dec 31, 2025

The Big 5 Things That Actually Matter

1. 🧵 Virtual Threads Are Now the Default

This is the headliner. In Spring Boot 3.2, virtual threads (Project Loom) were opt-in behind a flag. In 4.0, they're the recommended threading model on Java 21+ — the auto-configuration detects your JVM version and adjusts thread pools accordingly. No code changes required.

// Your existing blocking JDBC code? It just… works better now.
@GetMapping("/orders/{id}")
public Order getOrder(@PathVariable long id) {
    // Blocking call — but cheap on a virtual thread 🎉
    return orderRepository.findById(id).orElseThrow();
}

Tomcat and Jetty handlers use virtual threads by default on Java 21+. @Async tasks and scheduled operations follow the same model. The "virtual threads vs reactive" debate has largely been settled: for most standard I/O-heavy Spring MVC apps, you get reactive-scale throughput with imperative code simplicity.

One important caveat: virtual threads excel at I/O-bound workloads. CPU-intensive apps won't benefit as much, and you'll want to audit thread-local storage patterns since virtual threads can create millions of instances.

2. 🏗️ Modular Starter Redesign

The starters got a significant overhaul. Previously, pulling in spring-boot-starter-web dragged along a lot of optional integrations you might never use. The new design separates optional integrations (Micrometer, OpenTelemetry, specific persistence technologies) into dedicated modules.

The practical wins:

Faster builds — AOT processing has less unnecessary metadata to churn through
Cleaner dependency trees — only what you declare, not what Spring assumed you wanted
Better GraalVM native image support — fewer reflection hints needed for unused paths

If you use starter POMs, your pom.xml or build.gradle doesn't change. The modularization happens underneath. For teams doing native compilation, the build time improvements are immediately noticeable.

3. 🔢 Built-in API Versioning (Spring Framework 7)

Spring Framework 7 ships under the hood, and one of its headline features is first-class API versioning support — no more custom interceptors or messy URL path gymnastics.

@RestController
@RequestMapping("/api/greet")
public class GreetingController {

    @GetMapping(version = "1")
    public Map<String, String> greetV1() {
        return Map.of("message", "Hello!");
    }

    @GetMapping(version = "2")
    public Map<String, String> greetV2() {
        return Map.of(
            "message", "Hello!",
            "timestamp", LocalDateTime.now().toString()
        );
    }
}

Spring handles the routing. You declare the version; the framework dispatches it. For anyone building long-lived public APIs with multiple client generations, this alone is worth the upgrade conversation.

4. 📊 Unified Observability (OpenTelemetry + Micrometer)

The observability story in 4.0 is significantly cleaner. Configuration that previously required manual bean registration is now auto-configured:

Single property namespace for configuring OTLP exporters
Built-in trace-to-log correlation out of the box
Simplified Grafana and Prometheus setup through new starter dependencies
spring-boot-starter-actuator now includes observability defaults

# One block to rule your telemetry
management:
  otlp:
    tracing:
      endpoint: http://otel-collector:4318/v1/traces
  tracing:
    sampling:
      probability: 1.0

If you've been manually wiring ObservationRegistry beans or fighting with Micrometer context propagation, the new defaults will feel like a breath of fresh air.

5. 🚀 GraalVM AOT Goes Mainstream

Native image support has been in Spring since 3.0, but it always felt like a second-class citizen — reflection configuration was finicky, build times were brutal, and dynamic features broke in unexpected ways. Boot 4.0 changes that posture:

"Spring Boot 4.0 provides first-class framework support for both AOT compilation and virtual threads, eliminating the integration friction that plagued earlier adoption attempts."

The AOT engine now handles most common reflection patterns automatically. Third-party libraries increasingly ship GraalVM metadata out of the box. If you tried native images on 3.x and hit walls, it's worth retesting on 4.0.

Real-world benchmark from the Project Leyden team: Spring PetClinic starts 41% faster with AOT caching enabled in JDK 26. That's not GraalVM native territory, but it's approaching it — without rewriting code or giving up the JIT.

What Got Removed

Know before you upgrade:

Removed	Replacement
`WebSecurityConfigurerAdapter`	`SecurityFilterChain` beans
Undertow embedded server	Tomcat or Jetty (Undertow ≠ Servlet 6.1 compatible)
`spring.config.use-legacy-processing`	N/A — removed entirely
`RestTemplate` auto-configuration	`RestClient` (imperative) or `@HttpExchange` (declarative)
Spring Retry as separate dependency	Built-in resilience via `@Retry` and `@ConcurrencyLimit`

The RestTemplate one trips people up. It's not gone — but its auto-configuration is now opt-in. If you have RestTemplate beans autowired across your codebase, plan to migrate to RestClient:

// Old way (still works, but no longer auto-configured)
@Autowired
private RestTemplate restTemplate;

// New way — RestClient (Spring Framework 6.1+)
private final RestClient restClient = RestClient.create();

public String fetchData(String url) {
    return restClient.get()
        .uri(url)
        .retrieve()
        .body(String.class);
}

Migration Path

From Spring Boot 3.4/3.5 → 4.0: Smooth if you've been cleaning up deprecation warnings. No namespace migration (that was the 2.x → 3.x jump). Main watchpoints: Spring Security 7 new defaults, removed deprecated APIs, and JSpecify null-safety annotations.

From Spring Boot 2.x → 4.0: Don't do this in one shot. Migrate 2.x → 3.5 first, stabilize, then go to 4.0. You'll hit the javax.* to jakarta.* namespace change regardless, and stacking that on top of the 4.0 changes is pain you don't need.

<!-- Update your parent POM -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.0.6</version>
</parent>

Minimum Java version: 17. Recommended: 21 or 25 to actually benefit from virtual threads and the newer JVM features.

What's on the Horizon: Spring Boot 4.1

The 4.1.0-RC1 is already out with some interesting additions:

AMQP 1.0 spec support — auto-configuration of AmqpConnectionFactory and AmqpClient
Spring Batch + MongoDB — new spring-boot-batch-data-mongo module
Spring AI deeper integration — the ecosystem is converging on AI-native patterns fast

Spring AI deserves its own post, honestly — but the short version is that Java developers in 2026 have roughly the same toolkit for agentic AI development as Python developers, without needing to stand up separate services.

The Bottom Line

Spring Boot 4.0 isn't just an incremental patch release — it's a reset. Virtual threads make high-throughput I/O trivial. The modular redesign clears out years of accumulated dependency weight. Native images have finally crossed from "experimental" to "production-viable." And Spring Framework 7's API versioning fixes one of the oldest annoyances in REST API design.

If you're on 3.5.x, your support window closes June 30. If you're on 3.4.x or earlier, you're already in EOL territory. The upgrade path is genuinely smoother than 2.x → 3.x was — no namespace migration, just deprecation cleanup.

There's no good reason to wait.

Thanks for reading! Drop a 💬 if you've already migrated to 4.0 — curious what pain points you hit and what surprised you positively.

Redis 8.6 is here: faster, smarter, and built for AI-era workloads

Ashish Sharda — Mon, 20 Apr 2026 16:14:05 +0000

TL;DR: Redis 8.6 just went GA in open source. It brings more than 5× throughput over Redis 7.2, up to 35% lower latency on sorted sets, massive memory savings on hashes and sorted sets, production-grade Streams guarantees, hot key detection, smarter eviction, TLS auto-auth, and native NaN support in time series. Here's everything that matters.

01 — The numbers: performance at a glance
02 — Streams: at-most-once production guarantee
03 — Hot key detection with HOTKEYS
04 — New eviction policies for AI workloads
05 — TLS auto-auth via certificate CN
06 — NaN support in time series
07 — How to upgrade

01 — The numbers: performance at a glance

Redis 8.6 isn't a quiet patch release. This is a generational performance leap. On a single node using 16 cores (ARM Graviton4), Redis 8.6 hits 3.5M ops/sec at pipeline size 16. That's more than 5× the throughput of Redis 7.2 on the same hardware.

Metric	Improvement vs Redis 8.4
Sorted set commands latency	↓ 35%
GET latency (short strings)	↓ 15%
List commands latency	↓ 11%
Hash commands latency	↓ 7%
Sorted set memory footprint	↓ 30.5%
Hash memory footprint	↓ 16.7%
Vector insertion (VADD)	↑ 43%
Vector query performance	↑ 58%

Memory footprint improvements are just as notable: hashes shrink by up to 16.7%, sorted sets by up to 30.5%. That's real money saved on cloud infra.

💡 Benchmark context: Single node, 16 cores on an m8g.24xlarge (ARM Graviton4), 11 io-threads, pipeline size 16, 2000 clients, 1M keys, 1K string values, 1:10 SET:GET ratio.

02 — Streams: at-most-once production guarantee

Streams got a huge reliability upgrade. Redis 8.6 introduces idempotent production — a guarantee that a message will be added to a stream at most once, even when producers crash and retry.

This addresses a very real pain point in event-driven systems. When a producer sends a message, gets a network timeout, and retries — without this guarantee, you end up with duplicate events. Now Redis handles deduplication natively.

XADD mystream IDEM producer-id seq-123 * field value

Combined with the 8.2 multi-group acknowledgment and 8.4's pending message recovery, Streams in Redis 8.6 are genuinely production-ready for financial systems, media pipelines, and AI inference queues.

03 — Hot key detection with HOTKEYS

One of the trickiest production scaling problems — hot keys — now has a native Redis command. The new HOTKEYS command lets you detect keys consuming disproportionate CPU or network resources in real time.

HOTKEYS

This completes a trifecta of hot spot tooling across three releases:

Release	Feature	What it does
Redis 8.2	`CLUSTER SLOT-STATS`	Detect hot slots across the cluster
Redis 8.4	Atomic Slot Migration	Zero-downtime rebalancing of hot slots
Redis 8.6	`HOTKEYS`	Pinpoint individual hot keys causing load

Together, these give you end-to-end cluster observability — from slot to individual key — without reaching for external profiling tools.

04 — New eviction policies for AI workloads

Redis has long had LRU (least recently used) eviction. Now 8.6 introduces two new eviction policies based on least recently modified (LRM) semantics:

allkeys-lrm — evict the least recently modified key across all keys
volatile-lrm — same, but only among keys with a TTL set

Why does this matter for AI? In AI inference pipelines, a key might be read frequently (LRU keeps it hot) but rarely updated. LRM lets you evict stale model outputs or embedding caches that are no longer being written to — exactly the behavior you want when managing inference result caches at scale.

⚠️ Tip: If you're on allkeys-lru and running AI inference caches, consider evaluating allkeys-lrm — you may see better cache hit rates and more predictable memory behavior.

05 — TLS auto-auth via certificate CN

This one is genuinely slick. Prior to 8.6, even with mutual TLS configured, clients still had to send an AUTH command at the application layer. Starting with 8.6, Redis can automatically authenticate mTLS clients based on the certificate's Common Name (CN).

tls-auth-clients yes
tls-client-cert-auth-user-prefix acl-user-

Certificate possession becomes the sole credential. No more managing ACL passwords in your app config alongside TLS certs — the cert is the auth. This is huge for service mesh deployments and zero-trust architectures.

06 — NaN support in time series

Redis time series now supports NaN (Not a Number) values as a first-class way to represent missing measurements. Previously, teams used sentinel values like -1 or 0 which would corrupt aggregations.

TS.ADD sensor:temp 1714500000 NaN
TS.ADD sensor:temp 1714503600 23.4

Now you can mark a data point as "unavailable at collection time" and fill it in later, without breaking range queries or aggregations. Critical for telemetry pipelines, observability stacks, and financial data collection where gaps are expected.

07 — How to upgrade

Version	Status	Available in
8.6	✅ GA	Redis Open Source now; Cloud/Software soon
8.4	✅ GA	Redis Cloud (Essentials & Pro)
8.8	🔶 M02 preview	Docker Hub (not for production)

Pull Redis 8.6 via Docker:

docker pull redis:8.6
docker run -d --name redis86 -p 6379:6379 redis:8.6

Or grab it from redis.io/downloads. The release is backward compatible — a standard rolling upgrade applies for most configurations.

📦 If you're on Redis Cloud, 8.4 is already rolling out to Essentials and Pro. Redis 8.6 will follow into Cloud and Redis Software in upcoming releases. No action needed on managed offerings.

Redis 8.6 is one of the more meaningful releases in recent memory. The throughput and latency numbers are genuinely exciting, and the operational improvements — HOTKEYS, mTLS auto-auth, LRM eviction, Streams idempotency — close gaps that have been friction points for production teams for years. If you're running Redis in anger, this one is worth the upgrade.

Sources: Redis 8.6 announcement blog · What's new in two — March 2026

Java's Dark Corners: Things That Will Break You If You're Not Paying Attention

Ashish Sharda — Mon, 13 Apr 2026 02:59:09 +0000

You've been writing Java for years. You think you know it. You don't.

There's a special kind of confidence that comes after a few years of Java. You've survived generics. You've stared down the garbage collector. You've argued about whether checked exceptions were a mistake (they were). You feel safe.

You're not safe.

Java has corners. Dark ones. Places the docs gloss over, the tutorials skip, and the interviewer never asks about — until production is on fire at 2am and you're staring at a stack trace that makes no sense.

Let's go there.

1. `String.format` is not your friend under load

You've used it ten thousand times. It's readable. It's civilized. It's also one of the sneakiest performance traps in the JDK.

// Looks innocent. Isn't.
logger.debug(String.format("Processing order %s for user %s", orderId, userId));

Here's what most devs miss: String.format uses java.util.Formatter internally, which allocates a new Formatter object, a StringBuilder, and runs a regex-based parser on your format string — every single call.

In a hot path, this is brutal. Use String.valueOf() + concatenation (the compiler optimizes it to StringBuilder), or better yet — if you're on Java 15+ — text blocks and formatted() with proper caching.

And if you're still calling String.format inside a log statement without checking isDebugEnabled() first? Fix that before you close this tab.

2. `HashMap` has a trapdoor called hash collision amplification

You know HashMap degrades from O(1) to O(n) under hash collisions. Fine, textbook stuff. But here's what the textbook doesn't tell you:

Before Java 8, a pathological attacker (or a badly-designed key class) could reduce a HashMap to O(n) by simply engineering collisions. This was a real CVE. JSON parsing libraries that used HashMap for keys were vulnerable to hash-flooding DoS attacks.

After Java 8, the JDK added treeification — once a bucket hits 8 entries, it converts to a red-black tree, bringing worst case back to O(log n). But here's the trap:

record Point(int x, int y) {
    @Override
    public int hashCode() {
        return x ^ y; // "looks fine"
    }
}

(0,1) and (1,0) and (0,0) and... you see the problem. XOR is symmetric in ways that cluster your keys. In a spatial data structure with millions of points, you've just handed yourself a treeified nightmare.

Rule: If you override hashCode, use Objects.hash() or multiply by a prime. No cleverness.

3. `Optional` was never meant for what you're using it for

The original intent of Optional, per Brian Goetz himself: a return type for methods that might not have a value. That's it.

Not a field type. Not a method parameter. Not a collection element.

// Every senior dev has seen this and died inside
public class User {
    private Optional<String> middleName; // NO
}

Optional is not serializable. It doesn't play well with Jackson without custom configuration. It adds allocation overhead. And it signals to anyone reading your code that you fundamentally misread the javadoc.

The real dark corner: Optional.get() is worse than a null check. If you're calling get() without isPresent(), you've replaced a NullPointerException with a NoSuchElementException and gained nothing — except you now have to unwrap it manually and the compiler won't warn you.

Use orElse, orElseGet, map, filter. Or switch to Kotlin where nullability is a first-class citizen and this whole conversation disappears.

4. `==` on Integer will burn you exactly at ±127

This one is ancient. Senior devs know it. And senior devs still get burned by it, because it only fails at a specific threshold.

Integer a = 127;
Integer b = 127;
System.out.println(a == b); // true

Integer c = 128;
Integer d = 128;
System.out.println(c == d); // false

The JVM caches Integer instances for values between -128 and 127. Outside that range, autoboxing creates new objects. == compares references. You get false.

The reason this is dangerous for seniors specifically: you know to use .equals() for strings. You've internalized it. But Integer feels primitive enough that == feels right. It isn't.

Where this actually kills you in production: comparison logic in service layers that works fine in unit tests (with small IDs or status codes) and fails mysteriously with real data.

Always use .equals(). Always.

5. `ConcurrentHashMap` doesn't make your compound operations atomic

This is the one that humbles people.

ConcurrentHashMap is thread-safe. Individual operations like get, put, remove are atomic. But the moment you do two operations in sequence, you've lost the guarantee.

ConcurrentHashMap<String, Integer> counts = new ConcurrentHashMap<>();

// This is a race condition, full stop
if (!counts.containsKey(key)) {
    counts.put(key, 1);
} else {
    counts.put(key, counts.get(key) + 1);
}

Between containsKey and put, another thread can — and will — do the same thing. You now have the wrong count.

The fix: compute, computeIfAbsent, merge. These are atomic. The JDK gave you the tools in Java 8. Use them.

counts.merge(key, 1, Integer::sum); // atomic, correct, one line

The dark corner within the dark corner: putIfAbsent is also not the fix for the check-then-act pattern unless you are genuinely only initializing. Know which operation matches your intent.

6. The `finally` block can silently swallow your exception

try {
    throw new RuntimeException("the real problem");
} finally {
    throw new RuntimeException("the distraction");
}

What gets thrown? The second one. The original exception is gone. No chaining, no suppressed list, nothing. Your real error evaporated.

This is especially vicious with return in a finally block:

try {
    return computeSomething(); // throws
} finally {
    return fallback(); // silently wins
}

The exception is swallowed. The caller gets fallback()'s return value and has no idea anything went wrong. This pattern is a production debugging nightmare.

Rule: Never return or throw from finally. If you must catch in finally, use addSuppressed() to preserve the original exception.

7. Virtual threads will expose your hidden blocking code (and that's the point)

Java 21's virtual threads are genuinely transformative — but they're a lie detector, not a magic wand.

The pitch: mount thousands of virtual threads on a handful of OS threads. When a virtual thread blocks (I/O, sleep, etc.), it unmounts, freeing the carrier thread. Massive throughput with minimal resources.

The trap: synchronized blocks pin the virtual thread to its carrier.

synchronized (this) {
    someBlockingIoCall(); // pins the carrier thread. now you've lost the benefit.
}

With virtual threads, synchronized + blocking I/O is worse than before — you've created the illusion of concurrency while secretly serializing on your carrier pool.

The fix is to use ReentrantLock instead of synchronized. But that requires you to actually audit your code — including every library you've pulled in. If your JDBC driver uses synchronized internally, you're blocked.

Virtual threads don't make your code concurrent. They make your blocking code cheaper — as long as your blocking code cooperates.

The pattern underneath all of this

Notice what all seven of these have in common: they're not bugs. They're correct behavior that surprises you.

Java does exactly what the spec says. The problem is that the spec doesn't always match your mental model, and the gap between those two things is where production incidents live.

The senior move isn't memorizing this list. It's developing a healthy paranoia: when this seems too simple, what am I missing?

Write it down. Teach it to your team. And next time you're 100% sure about how something works in Java — go read the source.

What's your favorite Java dark corner? Drop it in the comments. I'll add the worst ones to a follow-up.

Java's Dark Corners: Things That Will Break You If You're Not Paying Attention

Ashish Sharda — Mon, 13 Apr 2026 02:59:09 +0000

You've been writing Java for years. You think you know it. You don't.

You're not safe.

Let's go there.

1. `String.format` is not your friend under load

You've used it ten thousand times. It's readable. It's civilized. It's also one of the sneakiest performance traps in the JDK.

// Looks innocent. Isn't.
logger.debug(String.format("Processing order %s for user %s", orderId, userId));

And if you're still calling String.format inside a log statement without checking isDebugEnabled() first? Fix that before you close this tab.

2. `HashMap` has a trapdoor called hash collision amplification

You know HashMap degrades from O(1) to O(n) under hash collisions. Fine, textbook stuff. But here's what the textbook doesn't tell you:

After Java 8, the JDK added treeification — once a bucket hits 8 entries, it converts to a red-black tree, bringing worst case back to O(log n). But here's the trap:

record Point(int x, int y) {
    @Override
    public int hashCode() {
        return x ^ y; // "looks fine"
    }
}

Rule: If you override hashCode, use Objects.hash() or multiply by a prime. No cleverness.

3. `Optional` was never meant for what you're using it for

The original intent of Optional, per Brian Goetz himself: a return type for methods that might not have a value. That's it.

Not a field type. Not a method parameter. Not a collection element.

// Every senior dev has seen this and died inside
public class User {
    private Optional<String> middleName; // NO
}

Use orElse, orElseGet, map, filter. Or switch to Kotlin where nullability is a first-class citizen and this whole conversation disappears.

4. `==` on Integer will burn you exactly at ±127

This one is ancient. Senior devs know it. And senior devs still get burned by it, because it only fails at a specific threshold.

Integer a = 127;
Integer b = 127;
System.out.println(a == b); // true

Integer c = 128;
Integer d = 128;
System.out.println(c == d); // false

The JVM caches Integer instances for values between -128 and 127. Outside that range, autoboxing creates new objects. == compares references. You get false.

The reason this is dangerous for seniors specifically: you know to use .equals() for strings. You've internalized it. But Integer feels primitive enough that == feels right. It isn't.

Where this actually kills you in production: comparison logic in service layers that works fine in unit tests (with small IDs or status codes) and fails mysteriously with real data.

Always use .equals(). Always.

5. `ConcurrentHashMap` doesn't make your compound operations atomic

This is the one that humbles people.

ConcurrentHashMap is thread-safe. Individual operations like get, put, remove are atomic. But the moment you do two operations in sequence, you've lost the guarantee.

ConcurrentHashMap<String, Integer> counts = new ConcurrentHashMap<>();

// This is a race condition, full stop
if (!counts.containsKey(key)) {
    counts.put(key, 1);
} else {
    counts.put(key, counts.get(key) + 1);
}

Between containsKey and put, another thread can — and will — do the same thing. You now have the wrong count.

The fix: compute, computeIfAbsent, merge. These are atomic. The JDK gave you the tools in Java 8. Use them.

counts.merge(key, 1, Integer::sum); // atomic, correct, one line

The dark corner within the dark corner: putIfAbsent is also not the fix for the check-then-act pattern unless you are genuinely only initializing. Know which operation matches your intent.

6. The `finally` block can silently swallow your exception

try {
    throw new RuntimeException("the real problem");
} finally {
    throw new RuntimeException("the distraction");
}

What gets thrown? The second one. The original exception is gone. No chaining, no suppressed list, nothing. Your real error evaporated.

This is especially vicious with return in a finally block:

try {
    return computeSomething(); // throws
} finally {
    return fallback(); // silently wins
}

The exception is swallowed. The caller gets fallback()'s return value and has no idea anything went wrong. This pattern is a production debugging nightmare.

Rule: Never return or throw from finally. If you must catch in finally, use addSuppressed() to preserve the original exception.

7. Virtual threads will expose your hidden blocking code (and that's the point)

Java 21's virtual threads are genuinely transformative — but they're a lie detector, not a magic wand.

The trap: synchronized blocks pin the virtual thread to its carrier.

synchronized (this) {
    someBlockingIoCall(); // pins the carrier thread. now you've lost the benefit.
}

With virtual threads, synchronized + blocking I/O is worse than before — you've created the illusion of concurrency while secretly serializing on your carrier pool.

Virtual threads don't make your code concurrent. They make your blocking code cheaper — as long as your blocking code cooperates.

The pattern underneath all of this

Notice what all seven of these have in common: they're not bugs. They're correct behavior that surprises you.

Java does exactly what the spec says. The problem is that the spec doesn't always match your mental model, and the gap between those two things is where production incidents live.

The senior move isn't memorizing this list. It's developing a healthy paranoia: when this seems too simple, what am I missing?

Write it down. Teach it to your team. And next time you're 100% sure about how something works in Java — go read the source.

What's your favorite Java dark corner? Drop it in the comments. I'll add the worst ones to a follow-up.

Java 25 LTS: The Game-Changer You've Been Waiting For

Ashish Sharda — Thu, 22 Jan 2026 00:39:07 +0000

The Java ecosystem is a vibrant and ever-evolving landscape. With a predictable release cadence, developers consistently receive powerful new features that enhance productivity, performance, and the overall developer experience. Among these releases, the Long-Term Support (LTS) versions stand out, offering extended stability and a commitment to long-term maintenance.

Enter Java 25 LTS, officially released on September 16, 2025. This isn't just another update; it's a monumental release packed with features that simplify the language for newcomers, slash boilerplate code for seasoned veterans, and supercharge performance, especially for emerging AI and data-intensive workloads.

1. Flexible Constructor Bodies (JEP 513)

For decades, Java constructors had a strict rule: the call to super() or this() had to be the very first statement. This led to awkward workarounds when you needed to validate parameters before delegating to a superclass.

Java 25 liberates us from this constraint. You can now place logic before the super() call.

Code Example:

After Java 25:

class PremiumUser extends User {
    private double discount;

    public PremiumUser(String name, int age, double discount) {
        // Validation logic BEFORE super()!
        if (discount < 0 || discount > 1.0) {
            throw new IllegalArgumentException("Discount must be between 0 and 1.");
        }
        super(name, age); 
        this.discount = discount;
    }
}

2. Compact Source Files & Instance Main Methods (JEP 512)

Java 25 dramatically lowers the barrier to entry by introducing Instance Main Methods. You no longer need public static void main(String[] args) or even an explicit class declaration for simple scripts.

Code Example:

// No class declaration, no 'static', no 'String[] args'
void main() {
    System.out.println("Hello, Java 25!");
    System.out.println("No more boilerplate for simple scripts.");
}

3. Module Import Declarations (JEP 511)

Instead of managing a wall of import statements, JEP 511 allows you to import an entire module with a single line.

Code Example:

// Imports all exported packages from java.base (List, Map, etc.)
import module java.base; 

public class MyUtility {
    List<String> names = new ArrayList<>();
    Map<String, Integer> scores = new HashMap<>();
}

4. Scoped Values (JEP 506)

ThreadLocal has long been the standard for sharing data across a thread, but it can be memory-intensive. Scoped Values offer a safer, more performant alternative, especially for Virtual Threads.

Code Example:

static final ScopedValue<String> CONTEXT = ScopedValue.newInstance();

void handleRequest() {
    ScopedValue.where(CONTEXT, "request-id-123").run(() -> {
        processTask();
    });
}

void processTask() {
    // Safely retrieve the scoped value
    System.out.println("Handling: " + CONTEXT.get());
}

5. Under-the-Hood: Performance & AI

While the syntax changes are exciting, the JVM itself received massive upgrades:

Compact Object Headers (JEP 519): Reduces object header size to 8 bytes. This significantly lowers the heap memory footprint for large-scale applications.
Vector API (10th Incubator): Continues to optimize high-performance math operations, critical for modern AI and Machine Learning workloads in Java.
Generational Shenandoah (JEP 521): Optimizes the Shenandoah GC for better handling of short-lived objects, reducing latency further.

6. Standardized Security: KDF API (JEP 510)

Java 25 introduces a native Key Derivation Function (KDF) API. This makes it easier to implement modern, secure password hashing (like Argon2) without relying on heavy third-party libraries.

Conclusion

Java 25 LTS is a landmark release. It bridges the gap between the power of an enterprise language and the ease of use found in modern scripting languages. Whether you are building AI-driven infrastructure or a simple microservice, Java 25 has something for you.

What are you most excited about in Java 25? Share your thoughts in the comments!

Stop Prompting, Start Orchestrating: Why 2026 is the Year the "Chatbot" Dies 💀

Ashish Sharda — Mon, 05 Jan 2026 02:27:14 +0000

CES 2026 is showing us physical robots, but the real revolution is happening in our terminals. Here’s why your "Prompt Engineering" certificate is already gathering dust.

The "Chatbot" is so 2024

Remember when we were all impressed that an LLM could write a Python script? We’d copy the prompt, paste the code, fix the bug, and repeat.

Fast forward to this week at CES 2026. We’re seeing robots like LG’s CLOiD folding laundry and navigating homes autonomously. They aren’t waiting for a "prompt" for every finger movement; they are orchestrating a goal.

As developers, we are hitting the same wall. Typing into a chat box is a bottleneck. In 2026, if you’re still just "chatting" with AI, you’re manually doing the work an agent should be doing for you.

From Prompts to "Agentic Workflows"

The shift we’re seeing right now is from stateless prompts to stateful orchestration. * Old Way: "Hey AI, write a test for this function." (One-shot, manual intervention).

2026 Way: An agentic loop using LangGraph or CrewAI that detects a new commit, identifies missing tests, writes them, runs the suite, fixes its own hallucinations, and only pings you on Slack when the PR is ready.

We aren't "prompt engineers" anymore. We are Agent Architects.

The 3 Pillars of the 2026 Stack

If you want to stay relevant this year, stop obsessing over which model is better (Gemini vs. GPT-x is a commodity now). Start obsessing over these three things:

Orchestration (The Brain): Moving beyond simple chains. We’re talking about "Manager Agents" that delegate to "Specialist Agents."
Tool-Use (The Hands): Teaching your AI to actually use your internal APIs, navigate your Jira, or even check your AWS billing.
Memory (The History): Giving agents a persistent state so they don’t "forget" what they did in the last deployment.

"Secure by Default" is the new vibe

With Microsoft flipping the switch on "Secure by Default" for Teams this week, the same applies to our agents. We can’t have "double agents" with unchecked access. 2026 is the year of Identity-based Agent Security. Every agent you build needs a scope, a permission set, and an audit log.

My Prediction: The "Agent OS"

By the end of this year, we won't be talking about "AI features." We’ll be talking about the Agent OS—a layer in our stack where autonomous workers live.

The question isn't whether AI will replace devs. The question is: Are you the dev who writes the code, or the dev who manages the 10 agents writing the code?

💬 Let’s Discuss

Are you moving your projects to a multi-agent setup yet? Or are you still team "Single Prompt"?

I'm curious—what’s the first task you’re handing off to a permanent agent this year?

Java Streams Explained: A Faster, Cleaner, More Powerful Way to Work With Collections

Ashish Sharda — Sat, 06 Dec 2025 13:27:05 +0000

Most developers start their Java journey writing loops — for, while, enhanced for, nested loops, and occasionally, loops inside database calls that we pretend aren't loops.

But modern applications generate and consume huge amounts of data, and iterating manually becomes:

❌ Verbose

❌ Error-prone

❌ Harder to maintain

❌ Not optimized for parallel execution

That's where Java Streams change the game.

What Exactly Is a Stream?

A Stream in Java is not a data structure — it's a pipeline that processes data in a functional style.

Think of a stream like water running through pipes:

✔ You can filter dirt

✔ You can change color

✔ You can collect it into a bottle

But the water is still the same water — the stream never stores it.

A stream has three stages:

Stage	Example	Responsibility
Source	List, Set, Array, Files	Where data flows from
Intermediate Ops	`map()`, `filter()`, `sorted()`	Transforming data
Terminal Ops	`collect()`, `forEach()`, `reduce()`	Producing output

Why Developers Love Streams

Without Streams	With Streams
More lines	Less code
Imperative logic	Functional style
Harder to parallelize	Built-in parallel
Tied to manual state	Stateless operations

Java streams allow you to write cleaner, faster, scalable code.

1️⃣Filtering Data (The Cleaner If-Condition)

List<Integer> nums = List.of(5, 12, 3, 20, 7);

List<Integer> result = nums.stream()
    .filter(n -> n > 10)
    .collect(Collectors.toList());

System.out.println(result); // [12, 20]

filter() returns only items that match the condition.

2️⃣ Transforming Values Using map()

List<String> names = List.of("ashish", "kumar");

List<String> upper = names.stream()
    .map(String::toUpperCase)
    .collect(Collectors.toList());

System.out.println(upper); // [ASHISH, KUMAR]

map() transforms each value without altering the original collection.

3️⃣ Sorting Made Simple

List<Integer> nums = List.of(8, 1, 6, 3);

List<Integer> sorted = nums.stream()
    .sorted()
    .collect(Collectors.toList());

System.out.println(sorted); // [1, 3, 6, 8]

You can also pass a custom comparator:

.sorted((a, b) -> b - a)

4️⃣ Reduce — Calculating a Single Result (Sum, Max, etc.)

int sum = nums.stream()
    .reduce(0, (a, b) -> a + b);

System.out.println(sum);

Reduce means: "Take all values → return one answer"

You can also compute maximum:

int max = nums.stream()
    .reduce(Integer::max)
    .get();

✨ Bonus: Streams & Objects (Real-World Use Case)

Let's say you have employees:

class Employee {
    String name; 
    int salary;

    Employee(String n, int s) { 
        name = n; 
        salary = s; 
    }
}

Extract names only:

List<String> namesOnly = employees.stream()
    .map(e -> e.name)
    .collect(Collectors.toList());

Filter high salary professionals:

List<Employee> highEarners = employees.stream()
    .filter(e -> e.salary > 100000)
    .collect(Collectors.toList());

Parallel Streams — Multithreading Without Threads

Just change:

employees.parallelStream()

Java will:

✔ Split workload across CPU cores

✔ Run tasks concurrently

✔ Auto merge the result

However — use carefully for:

❌ Very small collections

❌ Concurrent modification

✔ CPU-intensive operations

🧠 When to Use Streams (and When Not to)

Good For	Not Great For
Filtering	Very complex branching
Mapping	Code that relies on mutation
Aggregation	Debugging heavy logic
Parallel performance	Nested changing state

Streams are about data transformation, not updating shared variables.

🏁 Final Thoughts — Streams Make You Write Better Java

Java Streams aren't just a syntax trick — they encourage cleaner architecture:

🚀 No mutable state

🚀 Easier parallelization

🚀 Less code, same meaning

🚀 More declarative thinking

Once you start thinking in pipelines, your code naturally becomes:

Smaller
Faster
Easier to change
Easier to reason about

Java Streams don't just process data — they reshape how you think as a Java developer.

Have you started using Java Streams in your projects? What's been your experience? Drop a comment below and let's discuss how streams have changed your coding style!

About the Author: Ashish Sharda is a seasoned engineering leader with 15+ years of experience across companies like Apple, Salesforce, and Yahoo. He's passionate about teaching modern Java practices and helping developers write cleaner, more efficient code. Follow for more deep dives into Java and software engineering best practices.

DEV Community: Ashish Sharda

The IDE Is Dead. Long Live the Agent: What Google Antigravity 2.0 Actually Means for Developers

What Actually Shipped

Why This Is Bigger Than the Gemini Omni Demo

The Things Google Didn't Say Loudly Enough

The AGENTS.md Pattern

WebMCP: The Standard Nobody Is Talking About

The Pricing Reality Check

The Mental Model Shift

What I'd Do First

Final Take

I Work in Drone Traffic Management. Here's What Gemma 4 Changed.

What I Actually Needed (And Why Previous Models Fell Short)

The Model I Chose and Why It's the Right Tool

What I Built: SkyBrief

The Shift That Actually Matters

Honest Limitations

What Local AI Actually Means for High-Stakes Domains

SkyBrief: I Built a Drone Airspace Intelligence Tool with Gemma 4 26B MoE

What I Built

Demo

Code

How I Used Gemma 4

7 Things Java Devs Still Get Wrong in 2026 (Java 25/26 Edition)

1. Using Optional as a return type... everywhere

2. Ignoring Records for simple data carriers

3. Writing instanceof checks like it's 2010

4. Using ThreadLocal in a world that has ScopedValues

5. Spawning platform threads for everything concurrent

6. Skipping SequencedCollection for first/last element access

7. Treating Stream as a one-size-fits-all tool

The Bottom Line

I Built an AI Agent in Java (No Python. No Hype. Just Code.)

Why Java for AI? (The Short Version)

What We're Building

Project Setup

Dependencies (pom.xml)

Step 1 — Configure the Model and MCP

Step 2 — Build the MCP Tool Server

Step 3 — Wire the Agent (The Good Part)

Step 4 — The REST Endpoint

Let's See It Work

The Part That Gets Me

Switching AI Providers

What This Unlocks

The Takeaway

Spring Boot 4.0 Is Here — And It's a Big Deal 🍃

What Version Are We Even On?

The Big 5 Things That Actually Matter

1. 🧵 Virtual Threads Are Now the Default

2. 🏗️ Modular Starter Redesign

3. 🔢 Built-in API Versioning (Spring Framework 7)

4. 📊 Unified Observability (OpenTelemetry + Micrometer)

5. 🚀 GraalVM AOT Goes Mainstream

What Got Removed

Migration Path

What's on the Horizon: Spring Boot 4.1

The Bottom Line

Redis 8.6 is here: faster, smarter, and built for AI-era workloads

Table of Contents

01 — The numbers: performance at a glance

02 — Streams: at-most-once production guarantee

03 — Hot key detection with HOTKEYS

04 — New eviction policies for AI workloads

05 — TLS auto-auth via certificate CN

06 — NaN support in time series

07 — How to upgrade

Java's Dark Corners: Things That Will Break You If You're Not Paying Attention

1. String.format is not your friend under load

2. HashMap has a trapdoor called hash collision amplification

3. Optional was never meant for what you're using it for

4. == on Integer will burn you exactly at ±127

5. ConcurrentHashMap doesn't make your compound operations atomic

6. The finally block can silently swallow your exception

7. Virtual threads will expose your hidden blocking code (and that's the point)

The pattern underneath all of this

Java's Dark Corners: Things That Will Break You If You're Not Paying Attention

1. String.format is not your friend under load

2. HashMap has a trapdoor called hash collision amplification

3. Optional was never meant for what you're using it for

1. Using `Optional` as a return type... everywhere

3. Writing `instanceof` checks like it's 2010

4. Using `ThreadLocal` in a world that has `ScopedValues`

6. Skipping `SequencedCollection` for first/last element access

7. Treating `Stream` as a one-size-fits-all tool

1. `String.format` is not your friend under load

2. `HashMap` has a trapdoor called hash collision amplification

3. `Optional` was never meant for what you're using it for

4. `==` on Integer will burn you exactly at ±127

5. `ConcurrentHashMap` doesn't make your compound operations atomic

6. The `finally` block can silently swallow your exception

1. `String.format` is not your friend under load

2. `HashMap` has a trapdoor called hash collision amplification

3. `Optional` was never meant for what you're using it for

4. `==` on Integer will burn you exactly at ±127

5. `ConcurrentHashMap` doesn't make your compound operations atomic

6. The `finally` block can silently swallow your exception