Forem: Ashish Sharda

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.

Mastering Java Lambda Expressions: A Practical Guide for Modern Developers

Ashish Sharda — Wed, 03 Dec 2025 12:44:12 +0000

Java has evolved dramatically since the days of verbose anonymous classes. With Java 8, the language embraced functional programming through lambda expressions—and today, they're foundational: Streams, concurrency, collections, event handling, and reactive systems all depend on them.

If you're a working engineer who wants cleaner, more maintainable Java code, mastering lambdas isn't optional—it's essential.

Let's break down lambda expressions with real-world examples you can use immediately.

🔥 What Exactly Is a Lambda?

A lambda expression is a concise way to implement a functional interface—an interface with exactly one abstract method.

Before lambdas:

Runnable r = new Runnable() {
    @Override
    public void run() {
        System.out.println("Hello from thread!");
    }
};

With lambdas:

Runnable r = () -> System.out.println("Hello from thread!");

Same behavior. 80% less code. Infinitely more readable.

🎯 The Core Functional Interfaces

Java provides battle-tested functional interfaces in java.util.function. Here are the ones you'll use constantly:

Interface	Input	Output	When to Use
`Predicate<T>`	T	boolean	Filtering, validation
`Function<T,R>`	T	R	Transformations, mapping
`Consumer<T>`	T	void	Side effects (logging, saving)
`Supplier<T>`	none	T	Lazy initialization, factories
`BiFunction<T,U,R>`	T, U	R	Combining two inputs

Real examples:

// Validation
Predicate<String> isValidEmail = email -> email.contains("@");

// Transformation
Function<String, User> parseUser = json -> objectMapper.readValue(json, User.class);

// Side effects
Consumer<Order> saveOrder = order -> orderRepository.save(order);

// Factory
Supplier<String> generateId = () -> UUID.randomUUID().toString();

💡 Lambdas + Streams = Developer Superpowers

This is where lambdas transform how you process data.

Filtering:

List<Integer> evens = numbers.stream()
    .filter(n -> n % 2 == 0)
    .toList();

Chaining transformations:

List<String> processedNames = users.stream()
    .filter(user -> user.isActive())
    .map(User::getName)
    .map(String::toUpperCase)
    .sorted()
    .toList();

Aggregating:

int totalRevenue = orders.stream()
    .filter(order -> order.getStatus() == COMPLETED)
    .mapToInt(Order::getAmount)
    .sum();

This declarative style makes your intent crystal clear—no more nested loops and temporary variables.

🧩 Method References: Ultra-Compact Lambdas

When your lambda just calls a single method, use a method reference:

// Instead of: names.forEach(name -> System.out.println(name))
names.forEach(System.out::println);

// Instead of: ids.map(id -> userService.findById(id))
ids.map(userService::findById);

// Constructor reference
Stream.of("1", "2", "3")
    .map(Integer::new)
    .toList();

Four types exist:

Static method: Integer::parseInt
Instance method on object: System.out::println
Instance method on parameter: String::toUpperCase
Constructor: ArrayList::new

🔗 Lambdas Are Closures (With Guardrails)

Lambdas can capture variables from their enclosing scope, but there's a catch—they must be effectively final:

int multiplier = 10;
Function<Integer, Integer> scaler = x -> x * multiplier;
// multiplier = 20; // ❌ Compilation error!

Why? Thread safety and predictability. If you need mutable state, be explicit:

AtomicInteger counter = new AtomicInteger(0);
list.forEach(item -> {
    counter.incrementAndGet();
    process(item);
});

⚙️ Concurrency Made Simple

Lambdas dramatically clean up concurrent code:

Thread creation:

new Thread(() -> {
    runBackgroundTask();
    notifyCompletion();
}).start();

Executor service:

ExecutorService executor = Executors.newFixedThreadPool(4);
futures = tasks.stream()
    .map(task -> executor.submit(() -> processTask(task)))
    .toList();

CompletableFuture chaining:

CompletableFuture.supplyAsync(() -> fetchUserData())
    .thenApply(data -> transformData(data))
    .thenAccept(result -> saveResult(result))
    .exceptionally(ex -> handleError(ex));

✨ Elegant Sorting

Old school:

Collections.sort(people, new Comparator<Person>() {
    public int compare(Person a, Person b) {
        return a.getAge() - b.getAge();
    }
});

Modern Java:

// Simple
people.sort((a, b) -> a.getAge() - b.getAge());

// Better with method reference
people.sort(Comparator.comparing(Person::getAge));

// Complex sorting made readable
people.sort(Comparator
    .comparing(Person::getLastName)
    .thenComparing(Person::getFirstName)
    .reversed());

🛠 Custom Functional Interfaces

Build domain-specific abstractions:

@FunctionalInterface
interface PricingStrategy {
    BigDecimal calculatePrice(Product product, Customer customer);
}

PricingStrategy premium = (product, customer) -> 
    product.getBasePrice().multiply(new BigDecimal("0.9"));

PricingStrategy standard = (product, customer) -> 
    product.getBasePrice();

// Use it
BigDecimal price = pricingStrategy.calculatePrice(item, user);

This pattern keeps business logic modular and testable.

🛑 Common Pitfalls

❌ Lambda Too Complex

If your lambda spans multiple lines with complex logic, extract it:

// Bad
users.forEach(user -> {
    if (user.isActive() && user.getSubscription() != null) {
        Subscription sub = user.getSubscription();
        if (sub.isExpiring() && sub.getDaysLeft() < 7) {
            emailService.sendRenewalReminder(user);
        }
    }
});

// Good
users.stream()
    .filter(this::needsRenewalReminder)
    .forEach(emailService::sendRenewalReminder);

❌ Exception Handling Nightmares

Checked exceptions don't play nice with lambdas. Wrap them:

// Helper method
static <T> Consumer<T> wrap(CheckedConsumer<T> consumer) {
    return t -> {
        try {
            consumer.accept(t);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    };
}

// Usage
files.forEach(wrap(file -> Files.delete(file)));

❌ Performance Gotchas

Streams aren't always faster than loops for small datasets. Profile before optimizing:

// For small lists (<100 items), a simple loop might be faster
// For large datasets or complex transformations, streams win

⚡ Why This Matters

Lambdas fundamentally changed Java:

✅ Reduced boilerplate — Focus on logic, not ceremony

✅ Enabled Streams API — Declarative data processing

✅ Modern frameworks — Spring, Quarkus, Micronaut all leverage lambdas

✅ Reactive programming — Project Reactor, RxJava depend on them

✅ Better APIs — Fluent, chainable interfaces everywhere

Every modern Java framework, from Spring Boot to cloud SDKs, assumes you understand lambdas. They're not a "nice to have"—they're the foundation.

🧠 Final Thoughts

Lambdas didn't just remove boilerplate—they unlocked a new paradigm within Java. They bridge object-oriented and functional programming, making your code more expressive and maintainable.

Master them, and you'll write Java that's:

✔️ More concise
✔️ Easier to test
✔️ Better suited for modern architecture
✔️ Actually enjoyable to read

Start small. Replace one anonymous class today. Use forEach with a lambda tomorrow. Within weeks, you'll wonder how you ever coded without them.

What's your favorite lambda use case? Drop a comment below! 👇

Follow me for more practical Java guides and engineering leadership insights.

Introducing rapid-rs: Zero-Config Web Framework for Rust

Ashish Sharda — Tue, 18 Nov 2025 19:26:46 +0000

After years of building enterprise APIs at companies like Apple, Salesforce, and Visa, I kept hitting the same wall with Rust: setting up a new web service takes hours of wiring boilerplate.

You need to configure:

Database connections and pooling
Request validation
Error handling patterns
OpenAPI documentation
Logging and tracing
CORS
Configuration management
Project structure

Everyone does it differently. Every new service is a fresh adventure in dependency wiring.

The FastAPI Moment

Python developers had this problem too, until FastAPI came along. Suddenly, you could write:

@app.post("/users")
async def create_user(user: UserCreate):
    return user

And get automatic validation, serialization, and OpenAPI docs. That's the experience Rust deserves.

Enter rapid-rs

Today, I'm excited to launch rapid-rs - a zero-config web framework that brings FastAPI's developer experience to Rust.

Your First API in 3 Commands

# Install the CLI
cargo install rapid-rs-cli

# Create a project
rapid new myapi

# Run it
cd myapi && cargo run

Visit http://localhost:3000/docs and you've got a working API with Swagger UI. That's it.

What Does the Code Look Like?

Here's a complete, production-ready endpoint:

use rapid_rs::prelude::*;

#[derive(Deserialize, Validate)]
struct CreateUser {
    #[validate(email)]
    email: String,

    #[validate(length(min = 2, max = 100))]
    name: String,
}

#[derive(Serialize)]
struct User {
    id: Uuid,
    email: String,
    name: String,
    created_at: DateTime<Utc>,
}

async fn create_user(
    ValidatedJson(payload): ValidatedJson<CreateUser>
) -> ApiResult<User> {
    let user = User {
        id: Uuid::new_v4(),
        email: payload.email,
        name: payload.name,
        created_at: Utc::now(),
    };
    Ok(Json(user))
}

#[tokio::main]
async fn main() {
    App::new()
        .auto_configure()  // Magic happens here
        .route("/users", post(create_user))
        .run()
        .await
        .unwrap();
}

What Does `.auto_configure()` Give You?

✅ Configuration Management - Loads from TOML files + environment variables

✅ Request Validation - With helpful error messages

✅ Structured Logging - With request correlation IDs

✅ CORS - Sensible defaults, fully configurable

✅ Health Checks - /health endpoint ready

✅ OpenAPI/Swagger - Auto-generated docs at /docs

✅ Error Handling - Unified error responses

All working together, out of the box.

Why Not Just Use Axum?

Great question! Axum is excellent - in fact, rapid-rs is built on top of Axum.

The difference is philosophy:

Axum gives you powerful primitives (like Express.js)
rapid-rs gives you conventions and batteries (like NestJS or FastAPI)

Think of it this way:

Axum : Express.js
rapid-rs : NestJS/FastAPI

You can still use all Axum patterns when you need them. rapid-rs just makes the common path faster.

Real-World Example: CRUD API

Here's a complete user management API with validation:

use rapid_rs::prelude::*;
use std::sync::{Arc, Mutex};
use std::collections::HashMap;

type Database = Arc<Mutex<HashMap<Uuid, User>>>;

// Create
async fn create_user(
    State(db): State<Database>,
    ValidatedJson(payload): ValidatedJson<CreateUser>,
) -> ApiResult<User> {
    let user = User {
        id: Uuid::new_v4(),
        email: payload.email,
        name: payload.name,
        created_at: Utc::now(),
    };
    db.lock().unwrap().insert(user.id, user.clone());
    Ok(Json(user))
}

// Read
async fn get_user(
    State(db): State<Database>,
    Path(id): Path<Uuid>,
) -> Result<Json<User>, ApiError> {
    let user = db
        .lock()
        .unwrap()
        .get(&id)
        .ok_or_else(|| ApiError::NotFound(
            format!("User {} not found", id)
        ))?
        .clone();
    Ok(Json(user))
}

// List
async fn list_users(
    State(db): State<Database>
) -> ApiResult<Vec<User>> {
    let users: Vec<User> = db
        .lock()
        .unwrap()
        .values()
        .cloned()
        .collect();
    Ok(Json(users))
}

fn routes() -> Router<Database> {
    Router::new()
        .route("/users", post(create_user))
        .route("/users", get(list_users))
        .route("/users/:id", get(get_user))
}

#[tokio::main]
async fn main() {
    let db = Arc::new(Mutex::new(HashMap::new()));

    App::new()
        .auto_configure()
        .mount(routes().with_state(db))
        .run()
        .await
        .unwrap();
}

Run it and you get:

✅ All endpoints working
✅ Request validation
✅ Proper error responses
✅ Swagger UI documentation
✅ Health checks
✅ Request tracing

Configuration: The Right Way

Configuration loads from multiple sources (in priority order):

config/default.toml - Base settings
config/local.toml - Local overrides (gitignored)
Environment variables - APP__SERVER__PORT=8080

# config/default.toml
[server]
host = "0.0.0.0"
port = 3000

[database]
url = "postgres://localhost/mydb"
max_connections = 10

Override for production:

APP__SERVER__PORT=8080 cargo run

Type-safe, environment-aware, and follows the 12-factor app methodology.

Error Handling Done Right

Request validation errors automatically return helpful responses:

{
  "code": "VALIDATION_ERROR",
  "message": "Request validation failed",
  "errors": [
    {
      "field": "email",
      "message": "Invalid email format"
    },
    {
      "field": "name",
      "message": "Name must be between 2 and 100 characters"
    }
  ]
}

Custom errors are just as easy:

#[derive(Debug, Error, ApiError)]
pub enum MyError {
    #[error("User not found")]
    #[status(NOT_FOUND)]
    NotFound,

    #[error("Insufficient credits")]
    #[status(PAYMENT_REQUIRED)]
    InsufficientCredits,
}

Development Experience

Hot reload is built-in:

rapid dev  # Wraps cargo-watch

Project scaffolding creates everything you need:

rapid new myapi --template rest-api

Gets you:

myapi/
├── src/
│   └── main.rs        # Working example
├── config/
│   ├── default.toml   # Base config
│   └── local.toml     # Your overrides
├── Cargo.toml         # All dependencies ready
└── README.md          # Usage guide

Performance: Why Rust?

Let's be honest about the elephant in the room: why not just use FastAPI or Spring Boot?

Because Rust gives you:

10-100x faster than Python/Node.js
Memory safety without garbage collection
Zero-cost abstractions - pay only for what you use
Compile-time guarantees - catch bugs before production
Fearless concurrency - async by default

With rapid-rs, you don't trade productivity for performance. You get both.

Comparison Table

Feature	FastAPI	Spring Boot	rapid-rs
Type Safety	❌ Runtime	⚠️ Runtime	✅ Compile-time
Auto OpenAPI	✅	✅	✅
Hot Reload	✅	✅	✅
Zero Config	✅	✅	✅
Performance	⚠️ Good	⚠️ Good	✅ Excellent
Memory Safety	❌	❌	✅ Guaranteed
Async by Default	⚠️	❌	✅

What's Next?

This is v0.1.0 - an MVP with the core features working. Here's the roadmap:

Phase 2 (Next 2-3 weeks):

Authentication & Authorization (JWT, sessions)
Database migrations management
Testing utilities (TestApp::new().spawn())
More templates (GraphQL, gRPC)

Phase 3 (Future):

Background jobs
Multi-tenancy support
Feature flags
Admin panel generation

Try It Today

cargo install rapid-rs-cli
rapid new myapi
cd myapi && cargo run

Visit http://localhost:3000/docs and you're live!

Get Involved

rapid-rs is open source (MIT/Apache-2.0) and looking for contributors:

🌟 GitHub
💬 Issues and discussions welcome!

Why I Built This

At companies like Apple and Salesforce, I saw the same pattern: teams spending days wiring infrastructure before writing business logic. Python teams had FastAPI. Java teams had Spring Boot. Rust teams deserved better.

rapid-rs is my attempt to bring that same productivity to Rust, without sacrificing any of Rust's strengths.

If you've ever thought "I wish Rust web development was easier," this is for you.

What do you think? Try it out and let me know! I'm actively working on this and would love your feedback.

⭐ Star the repo: https://github.com/ashishjsharda/rapid-rs

💬 Questions? Open an issue or comment below!

The 2025 Paradigm Shift: Why React Devs Are Ditching Traditional Component Libraries

Ashish Sharda — Tue, 04 Nov 2025 12:34:45 +0000

The React ecosystem just went through a quiet revolution, and most developers are still catching up.

The Old Way (2020-2024)

Traditional component libraries dominated:

Material-UI
Ant Design
Chakra UI

Developers accepted:

❌ 320KB CSS bundles
❌ CSS specificity wars
❌ Days to implement design changes
❌ Fighting !important overrides constantly

The New Way (2025)

Headless architecture + utility-first CSS is taking over:

✅ Radix UI / React Aria (behavior & accessibility)
✅ Tailwind CSS (styling)
✅ shadcn/ui (copy-paste components you own)

Real results from companies that switched:

91% smaller CSS (320KB → 28KB)
3x faster page loads (2.8s → 0.9s FCP)
36x faster design iterations (3 days → 2 hours)

Why This Shift Is Happening Now

Separation of concerns done right:

Headless libraries handle accessibility and behavior
You handle styling with utilities
No more black-box component dependencies
Zero runtime styling overhead

The shadcn/ui model is genius:
Instead of npm install, you copy the code into your project.

You own it 100%
No breaking changes from updates
Full customization freedom
66k+ GitHub stars for a reason

The Bottom Line

If you're starting a React project in 2025 with traditional component libraries, you're choosing technical debt from day one.

📖 Want the Complete Guide?

This is just scratching the surface. I wrote an in-depth 18-minute guide covering:

✅ Detailed comparison of all major headless libraries (Radix, React Aria, Headless UI, Base UI)
✅ Best practices for combining with Tailwind CSS
✅ Real migration case studies with metrics
✅ Component composition patterns with code examples
✅ 7-day migration roadmap
✅ When NOT to use headless architecture
✅ Complete tooling ecosystem breakdown
✅ Performance optimization strategies
✅ Common pitfalls and how to avoid them

👉 Read the full article on Medium →

The article includes:

8 interactive diagrams
Real code examples
Architecture comparisons
Decision-making frameworks
Comprehensive resource links

What's your experience with headless libraries? Drop a comment below! 💬

If you found this valuable, the full article goes 10x deeper. Check it out! 🚀

Follow me for more insights on modern React development and web architecture.

🚀 Rust 1.90: The Build Speed Revolution We’ve Been Waiting For

Ashish Sharda — Mon, 20 Oct 2025 03:42:17 +0000

Rust 1.90 isn’t just a point release — it’s a productivity milestone.
Here’s what’s inside:

🧠 LLD linker = 7× faster incremental builds on Linux

⚙️ 40 % overall compile speedup (no code edits required)

🔁 Workspace publishing in a single command

If you spend your life watching compilers, this release is like hitting turbo mode.
👉 Read my deep divefor benchmarks and upgrade tips.

rust #performance #developerproductivity #rustlang

Forem: Ashish Sharda

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

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 25 LTS: The Game-Changer You've Been Waiting For

1. Flexible Constructor Bodies (JEP 513)

Code Example:

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

Code Example:

3. Module Import Declarations (JEP 511)

Code Example:

4. Scoped Values (JEP 506)

Code Example:

5. Under-the-Hood: Performance & AI

6. Standardized Security: KDF API (JEP 510)

Conclusion

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

The "Chatbot" is so 2024

From Prompts to "Agentic Workflows"

The 3 Pillars of the 2026 Stack

"Secure by Default" is the new vibe

My Prediction: The "Agent OS"

💬 Let’s Discuss

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

What Exactly Is a Stream?

Why Developers Love Streams

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

2️⃣ Transforming Values Using map()

3️⃣ Sorting Made Simple

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

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

What Does `.auto_configure()` Give You?