DEV Community: Said Olano

Understanding Java's Virtual Threads: A Game-Changer for Concurrency

Said Olano — Fri, 07 Aug 2026 01:01:56 +0000

Understanding Java's Virtual Threads: A Game-Changer for Concurrency

Java 21 introduced one of the most significant features in the language's history: virtual threads (Project Loom). If you've ever struggled with the overhead of platform threads in high-concurrency applications, this feature is for you.

The Problem with Platform Threads

Traditionally, each Java thread maps directly to an OS thread. These are expensive:

Each thread consumes around 1MB of stack memory
Context switching has significant overhead
Creating thousands of threads can exhaust system resources

This forced developers into complex asynchronous programming models using CompletableFuture or reactive frameworks, which sacrifice readability.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM rather than the OS. You can create millions of them without breaking a sweat.

java
// Creating a virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread!");
});

// Using an executor
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 10_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return i;
});
});
}

How It Works

Virtual threads run on top of a small pool of carrier threads (platform threads). When a virtual thread blocks on I/O, the JVM unmounts it from its carrier thread, freeing that carrier to run other virtual threads. This is called mounting and unmounting.

java
// This blocking call no longer wastes an OS thread
String response = httpClient.send(request, BodyHandlers.ofString()).body();

Benefits

Simpler code — Write straightforward blocking code that scales
Better throughput — Handle massive concurrent workloads
No API changes — Existing code works with minimal modifications

Best Practices

Avoid pooling virtual threads — They're cheap; create new ones as needed
Watch for pinning — Synchronized blocks can pin a virtual thread to its carrier; prefer ReentrantLock
Don't use them for CPU-bound tasks — They shine with I/O-bound work

java
// Prefer ReentrantLock over synchronized to avoid pinning
private final ReentrantLock lock = new ReentrantLock();

public void safeOperation() {
lock.lock();
try {
// critical section
} finally {
lock.unlock();
}
}

Conclusion

Virtual threads let you write simple, synchronous-style code that scales to handle enormous concurrency. For server applications juggling thousands of requests, they represent a major leap forward—combining the readability of blocking code with the scalability of reactive systems.

Give them a try in your next Spring Boot project (Spring Boot 3.2+ supports them natively) and experience the difference!

HazelCast: Distributed Computing Platform

Said Olano — Thu, 06 Aug 2026 21:57:35 +0000

HazelCast: Distributed Computing Platform

Distributed systems are complex. Managing data across multiple nodes, ensuring consistency, handling failures—these challenges grow exponentially as your application scales. That's where HazelCast enters the picture. It's an in-memory data grid and distributed computing platform that makes building scalable, fault-tolerant applications surprisingly approachable.

What Is HazelCast?

At its core, HazelCast is an open-source, distributed in-memory data grid (IMDG) written in Java. Think of it as a distributed cache on steroids: it stores data in memory across a cluster of machines, allowing you to access that data with sub-millisecond latency while maintaining high availability and automatic failover.

Unlike traditional caching layers that sit passively between your app and database, HazelCast actively participates in your system. It offers distributed queues, maps, topics, locks, and semaphores—all synchronized across nodes automatically. No heartbeat requests, no stale copies: when one node updates a value, every other node sees the change immediately.

Why HazelCast Matters for Java Developers

Speed: In-memory operations are orders of magnitude faster than disk or network I/O. HazelCast gives you that speed without the complexity of managing a separate distributed system.

High Availability: Data is automatically replicated across cluster members. If one node crashes, your data survives. If the network partitions, HazelCast can be configured to handle split-brain scenarios gracefully.

Embedded or Managed: Run HazelCast as an embedded library inside your Spring Boot app, or connect to a standalone server cluster. Both approaches work seamlessly—your code doesn't change.

Built for the JVM: Native Java support, Spring integration, and Kubernetes operators mean it feels native to your stack, not like a third-party bolted-on tool.

A Practical Example

// Start an embedded HazelCast instance
HazelcastInstance instance = Hazelcast.newHazelcastInstance();

// Get a distributed map
IMap<String, String> config = instance.getMap("config");

// Put data (replicated across the cluster automatically)
config.put("feature_flag_new_ui", "enabled");

// Read from any node—same result
String flag = config.get("feature_flag_new_ui"); // "enabled"

// Listen for changes
config.addEntryListener((event) -> {
    System.out.println("Config updated: " + event.getKey());
}, false);

That's it. Your app now has a shared, distributed data store, and every node in your cluster sees updates in real-time.

When to Use HazelCast

Session storage: Distributed web sessions across multiple app instances without sticky sessions.

Configuration management: Shared config that updates live across the cluster.

Rate limiting & quotas: Distributed counters and atomic references ensure fairness.

Real-time analytics: Stream events through distributed topics, aggregate results in memory.

Distributed locks: Ensure critical sections run safely across a cluster.

The Tradeoffs

HazelCast isn't a silver bullet. All data lives in memory, so heap size is your limit. Network partitions and Byzantine failure modes demand careful configuration. And like any distributed system, debugging becomes harder—partial failures and timing issues can be tricky to reproduce.

But for Java teams building microservices, especially those already using Spring Boot and Kubernetes, HazelCast brings order to the chaos of distributed state management. It abstracts away the plumbing and lets you focus on business logic.

Next Steps

Start with the embedded mode—add it to a Spring Boot app, experiment with distributed maps, and feel how natural it becomes. The official docs are excellent, and the community is active. Once you've felt the power of instant, replicated data across your cluster, you'll wonder how you ever built distributed systems without it.

Have you used HazelCast in production? What problems did it solve for your team?

Understanding Java's Virtual Threads: A Practical Guide to Project Loom

Said Olano — Wed, 05 Aug 2026 22:16:17 +0000

Understanding Java's Virtual Threads: A Practical Guide to Project Loom

Java 21 introduced one of the most significant additions to the platform in years: virtual threads, delivered through Project Loom. If you've ever struggled with thread-per-request scalability limits, this feature is a game changer.

The Problem with Platform Threads

Traditional Java threads (now called platform threads) are thin wrappers around operating system threads. Each one consumes roughly 1MB of stack memory and mapping is 1:1 with an OS thread. This means creating tens of thousands of them is expensive and often impractical.

java
// The old approach - limited by OS thread count
ExecutorService executor = Executors.newFixedThreadPool(200);
for (int i = 0; i < 10_000; i++) {
executor.submit(() -> {
// blocking I/O ties up a precious OS thread
return fetchFromDatabase();
});
}

When a platform thread blocks on I/O, the underlying OS thread sits idle, wasting resources.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM, not the OS. Thousands or even millions can run concurrently. When a virtual thread blocks, it is unmounted from its carrier (platform) thread, freeing that carrier to run other work.

java
// The new approach - one virtual thread per task
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 1_000_000; i++) {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return fetchFromDatabase();
});
}
}

You can also create them directly:

java
Thread vThread = Thread.ofVirtual().start(() -> {
System.out.println("Running in " + Thread.currentThread());
});
vThread.join();

Key Benefits

Massive scalability: Millions of concurrent tasks without exhausting memory.
Simple programming model: Write straightforward blocking code instead of complex reactive chains.
No API changes: Existing Thread and ExecutorService code works with minimal modification.

Watch Out for Pinning

Virtual threads can become pinned to their carrier thread in certain scenarios, preventing unmounting:

java
// synchronized blocks can pin the virtual thread
synchronized (lock) {
performBlockingIO(); // carrier thread stays occupied!
}

Prefer ReentrantLock over synchronized for blocking sections:

java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
performBlockingIO();
} finally {
lock.unlock();
}

Integration with Spring Boot

Spring Boot 3.2+ supports virtual threads out of the box. Enable them with a single property:

properties
spring.threads.virtual.enabled=true

This makes Tomcat serve each request on a virtual thread, dramatically improving throughput for I/O-bound applications without rewriting your controllers.

When to Use Them

Virtual threads shine for I/O-bound workloads with high concurrency. For CPU-bound tasks, stick with a bounded pool of platform threads, since virtual threads offer no advantage when the CPU is the bottleneck.

Conclusion

Virtual threads let you write simple, readable, blocking-style code while achieving the scalability previously reserved for reactive frameworks. As Java continues to evolve, mastering Project Loom will be essential for building high-performance backend systems.

Give them a try in your next project—your code and your servers will thank you.

Understanding Java Virtual Threads: Lightweight Concurrency in Java 21

Said Olano — Mon, 03 Aug 2026 22:12:57 +0000

Understanding Java Virtual Threads: Lightweight Concurrency in Java 21

Java 21 introduced one of the most significant additions to the platform in years: virtual threads (Project Loom). This feature fundamentally changes how we write concurrent applications in Java, making high-throughput concurrent code both simpler and more scalable.

The Problem with Platform Threads

Traditionally, every Java Thread maps directly to an operating system thread. These platform threads are expensive:

Each consumes roughly 1MB of stack memory.
Context switching is handled by the OS and is relatively costly.
A typical machine can only support a few thousand of them.

This limitation forced developers toward complex asynchronous programming models (callbacks, CompletableFuture chains, reactive streams) to achieve scalability—at the cost of readability and debuggability.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM rather than the OS. Millions of them can run on just a handful of platform threads (called carrier threads). When a virtual thread blocks on I/O, the JVM unmounts it from its carrier thread, freeing that carrier to run other work.

Creating a Virtual Thread

java
// Start a single virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread!");
});

// Using a builder
Thread vThread = Thread.ofVirtual()
.name("worker-", 0)
.start(() -> doWork());

Executor Service with Virtual Threads

The most idiomatic way to use them is via an executor:

java
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 10_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return i;
});
});
} // executor.close() waits for all tasks to finish

This spawns 10,000 concurrent tasks. With platform threads this would likely exhaust system resources, but with virtual threads it runs comfortably.

Writing Simple Blocking Code Again

The beauty of virtual threads is that you write straightforward blocking code, and the JVM handles the scaling:

java
String fetchUserData(int userId) {
var user = userService.findById(userId); // blocking call
var orders = orderService.findByUser(userId); // blocking call
return combine(user, orders);
}

No reactive chains, no callbacks—just readable, debuggable, sequential logic.

Spring Boot Support

Spring Boot 3.2+ supports virtual threads with a single property:

properties
spring.threads.virtual.enabled=true

Once enabled, Tomcat serves each request on a virtual thread, dramatically increasing the number of concurrent requests the server can handle without tuning thread pools.

Pitfalls to Watch For

Pinning: When a virtual thread runs inside a synchronized block during a blocking call, it stays pinned to its carrier thread. Prefer ReentrantLock instead.
Don't pool virtual threads: They are cheap to create. Use newVirtualThreadPerTaskExecutor() rather than a fixed pool.
CPU-bound work: Virtual threads shine for I/O-bound tasks. For CPU-bound work, the number of platform threads is still the limiting factor.

Conclusion

Virtual threads let you keep the simple thread-per-request programming model while achieving the scalability previously reserved for asynchronous frameworks. If you're on Java 21 or later, they're one of the easiest performance wins available—especially in I/O-heavy services.

Try enabling them in your next Spring Boot project and measure the difference!

Understanding Java Virtual Threads: Lightweight Concurrency in Java 21

Said Olano — Mon, 03 Aug 2026 17:10:16 +0000

Understanding Java Virtual Threads: Lightweight Concurrency in Java 21

Java 21 introduced one of the most significant additions to the platform in years: virtual threads, delivered as part of Project Loom. If you've ever struggled with the overhead of managing thousands of platform threads, virtual threads are about to change the way you write concurrent applications.

The Problem with Platform Threads

Traditional Java threads (now called platform threads) are thin wrappers around operating system threads. Each one consumes a significant amount of memory (typically around 1MB for the stack) and creating them is expensive. This forces developers into complex patterns like thread pools and asynchronous, callback-heavy code to achieve scalability.

java
// Traditional approach with a bounded thread pool
ExecutorService executor = Executors.newFixedThreadPool(200);
executor.submit(() -> handleRequest());

With this model, if all 200 threads are blocked on I/O, new requests must wait.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM rather than the OS. You can create millions of them without exhausting system resources. When a virtual thread blocks on I/O, it is unmounted from its carrier (platform) thread, freeing that carrier to run other virtual threads.

java
// Creating a virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread!");
});

// Using an executor that creates a new virtual thread per task
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 1_000_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return i;
});
});
}

The example above spawns a million tasks. With platform threads this would be impossible; with virtual threads it works comfortably.

Key Benefits

Scalability: Handle massive numbers of concurrent tasks with a simple blocking style.
Simplicity: Write straightforward, synchronous-looking code instead of complex reactive chains.
Compatibility: Virtual threads implement java.lang.Thread, so existing APIs work unchanged.

Using Virtual Threads in Spring Boot

Spring Boot 3.2+ makes enabling virtual threads trivial. Just add this to your application.properties:

properties
spring.threads.virtual.enabled=true

This configures Tomcat (or your embedded server) to handle each request on a virtual thread, dramatically improving throughput for I/O-bound web applications.

Things to Watch Out For

Pinning: When a virtual thread runs inside a synchronized block during a blocking call, it stays pinned to its carrier thread. Prefer ReentrantLock for critical sections that wrap I/O.
Thread pools are unnecessary: Don't pool virtual threads. Create a new one per task instead.
CPU-bound work: Virtual threads shine for I/O-bound workloads, not CPU-intensive computation.

Conclusion

Virtual threads bring the simplicity of synchronous code together with the scalability previously reserved for reactive frameworks. As you migrate to Java 21 and Spring Boot 3.2+, consider adopting virtual threads to simplify your concurrent code while boosting performance. The future of Java concurrency is lightweight, and it's here today.

Understanding Java's Virtual Threads: A Practical Guide

Said Olano — Sun, 02 Aug 2026 22:00:58 +0000

Understanding Java's Virtual Threads: A Practical Guide

Java 21 introduced one of the most significant changes to the platform's concurrency model in years: virtual threads. Finalized under JEP 444, virtual threads dramatically simplify writing high-throughput concurrent applications. In this post, we'll explore what they are, why they matter, and how to use them.

The Problem with Platform Threads

Traditionally, every java.lang.Thread in the JVM maps directly to an operating system thread. These platform threads are expensive:

Each one consumes around 1MB of stack memory by default.
The OS scheduler limits how many you can realistically create (typically a few thousand).
Blocking a platform thread wastes a scarce resource.

This forced developers into asynchronous, callback-heavy programming models to scale, sacrificing readability and debuggability.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM rather than the OS. Millions can run concurrently because they are cheap to create and don't tie up an OS thread while blocked.

java
// Creating and starting a virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread!");
});

// Using an ExecutorService backed by virtual threads
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 10_000; i++) {
int taskId = i;
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return taskId;
});
}
}

When a virtual thread hits a blocking operation (like I/O), the JVM unmounts it from its carrier platform thread, freeing that carrier to run other work. When the operation completes, the virtual thread is remounted.

Writing Simple, Blocking Code

The key benefit is that you can write straightforward, synchronous code that scales:

java
void handleRequest(Socket socket) throws IOException {
try (var in = socket.getInputStream();
var out = socket.getOutputStream()) {
byte[] data = in.readAllBytes(); // blocking is fine!
out.write(process(data));
}
}

No CompletableFuture chains, no reactive operators—just readable, debuggable code.

Pitfalls to Avoid

Don't pool virtual threads. They're cheap; create a new one per task.
Watch for pinning. Blocking inside a synchronized block pins the virtual thread to its carrier. Prefer ReentrantLock for critical sections that block.
Avoid thread-local abuse. With millions of threads, heavy ThreadLocal usage can inflate memory.

java
// Prefer this over synchronized when blocking
private final ReentrantLock lock = new ReentrantLock();

void safeOperation() {
lock.lock();
try {
performBlockingIO();
} finally {
lock.unlock();
}
}

Conclusion

Virtual threads let Java developers return to a simple thread-per-request model while achieving the scalability once reserved for asynchronous frameworks. If you're building I/O-bound services, upgrading to Java 21+ and adopting virtual threads can simplify your codebase and boost throughput with minimal effort.

Understanding Java Virtual Threads: Lightweight Concurrency in Modern Java

Said Olano — Sat, 01 Aug 2026 22:02:56 +0000

Understanding Java Virtual Threads: Lightweight Concurrency in Modern Java

Java 21 introduced one of the most significant changes to the platform's concurrency model in years: virtual threads, delivered as part of Project Loom (JEP 444). If you've ever struggled with thread pool tuning or hit scalability walls with blocking I/O, virtual threads are worth understanding.

The Problem with Platform Threads

Traditional Java threads (now called platform threads) are thin wrappers around operating system threads. They are expensive:

Each thread consumes around 1 MB of stack memory by default.
The OS scheduler manages context switching, which adds overhead.
A typical machine can only support a few thousand concurrent platform threads before running into resource limits.

This led to the popularity of asynchronous, reactive programming styles that avoid blocking. But reactive code is notoriously hard to read, debug, and maintain.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM rather than the operating system. Millions of them can run concurrently, and they are mapped onto a small pool of platform threads (called carrier threads).

When a virtual thread blocks on I/O, the JVM automatically unmounts it from its carrier thread, freeing that carrier to run other virtual threads.

Creating Virtual Threads

The API is refreshingly simple:

java
// Start a single virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread");
});

// Using a builder
Thread vThread = Thread.ofVirtual()
.name("worker-1")
.start(() -> doWork());

The real power shows up with executors:

java
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 10_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return i;
});
});
}

This code spawns 10,000 concurrent tasks. With platform threads this would likely exhaust system resources; with virtual threads it runs comfortably.

Writing Simple, Blocking Code Again

The biggest win is that you can write straightforward, synchronous-looking code that still scales:

java
var response = httpClient.send(request, BodyHandlers.ofString());
process(response.body());

The blocking call no longer wastes a precious OS thread. The scheduler handles the rest.

Best Practices

Don't pool virtual threads. They are cheap to create. Use newVirtualThreadPerTaskExecutor() instead of a fixed pool.
Avoid synchronized blocks around blocking I/O. They can pin the virtual thread to its carrier. Prefer ReentrantLock.
Use them for I/O-bound tasks. For CPU-bound work, platform threads still make sense.

Conclusion

Virtual threads let you keep the simplicity of blocking code while achieving the scalability once reserved for reactive frameworks. Combined with frameworks like Spring Boot, which now support virtual threads out of the box, they represent a meaningful step forward for Java server-side development.

Try them in your next project and measure the difference for yourself.

Understanding Java Virtual Threads: A Practical Guide

Said Olano — Sat, 01 Aug 2026 15:41:22 +0000

Understanding Java Virtual Threads: A Practical Guide

Java 21 introduced virtual threads as a stable feature (JEP 444), fundamentally changing how we write concurrent applications. In this post, we'll explore what they are, why they matter, and how to use them effectively.

What Are Virtual Threads?

Traditional Java threads (platform threads) map directly to operating system threads. Each OS thread consumes significant memory (often 1MB+ of stack) and context-switching is expensive. This limits applications to a few thousand concurrent threads.

Virtual threads are lightweight threads managed by the JVM rather than the OS. Millions of them can run on a small pool of carrier (platform) threads.

The Problem They Solve

Consider a typical web server handling blocking I/O:

java
// Traditional approach - limited by OS threads
ExecutorService executor = Executors.newFixedThreadPool(200);
executor.submit(() -> {
var response = httpClient.send(request); // blocks the thread
process(response);
});

With only 200 threads, high I/O concurrency becomes a bottleneck. Virtual threads eliminate this constraint.

Creating Virtual Threads

java
// Create and start a single virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread");
});

// Using an ExecutorService (recommended)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 1_000_000; i++) {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return "done";
});
}
} // executor.close() waits for all tasks

This code launches a million tasks without exhausting system resources.

How It Works Under the Hood

When a virtual thread hits a blocking operation (like I/O), the JVM unmounts it from its carrier thread and parks it. The carrier thread is freed to run other virtual threads. When the blocking call completes, the virtual thread is remounted and resumes execution.

Best Practices

Don't pool virtual threads — they're cheap to create. Use newVirtualThreadPerTaskExecutor().
Avoid synchronized blocks for long operations, as they can pin the virtual thread to its carrier. Prefer ReentrantLock.
Keep ThreadLocals minimal — with millions of threads, they can consume significant memory.

java
// Prefer ReentrantLock over synchronized
private final ReentrantLock lock = new ReentrantLock();

void safeUpdate() {
lock.lock();
try {
// critical section
} finally {
lock.unlock();
}
}

Virtual Threads in Spring Boot

Spring Boot 3.2+ makes enabling virtual threads trivial:

properties
spring.threads.virtual.enabled=true

This configures Tomcat and other components to use virtual threads for request handling.

Conclusion

Virtual threads let you write simple, blocking-style code that scales like asynchronous code. They preserve the readability of synchronous programming while unlocking massive concurrency — a genuine win for backend developers.

Start experimenting with them today, and rethink whether reactive complexity is still necessary for your I/O-bound workloads.

Understanding Java Virtual Threads: Lightweight Concurrency in Java 21

Said Olano — Sat, 01 Aug 2026 15:40:08 +0000

Understanding Java Virtual Threads: Lightweight Concurrency in Java 21

Java 21 introduced one of the most significant additions to the platform in years: virtual threads, delivered as part of Project Loom (JEP 444). This feature fundamentally changes how we write high-throughput concurrent applications in Java.

The Problem with Platform Threads

Traditionally, each Java thread maps directly to an operating system thread. These platform threads are expensive:

Each thread consumes roughly 1MB of stack memory.
Context switching is handled by the OS and carries overhead.
The number of threads is limited (typically a few thousand).

For I/O-bound applications like web servers, this becomes a bottleneck. You end up either blocking threads (wasting resources) or adopting complex asynchronous, reactive programming models.

Enter Virtual Threads

Virtual threads are lightweight threads managed by the JVM rather than the OS. Millions of them can run on a small pool of platform threads (called carrier threads).

java
// Creating a virtual thread
Thread.startVirtualThread(() -> {
System.out.println("Running in a virtual thread!");
});

// Using an ExecutorService
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 1_000_000; i++) {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return null;
});
}
}

The key insight: when a virtual thread blocks on I/O, the JVM unmounts it from its carrier thread, freeing that carrier to run other virtual threads. When the I/O completes, the virtual thread is remounted and resumes.

Writing Simple, Blocking Code Again

The biggest win is that you can write straightforward, blocking code that scales:

java
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
Future user = executor.submit(() -> fetchUser());
Future order = executor.submit(() -> fetchOrder());
String result = user.get() + " | " + order.get();
System.out.println(result);
}

No callbacks, no reactive chains—just clean, readable code.

Spring Boot Integration

Spring Boot 3.2+ supports virtual threads with a single property:

properties
spring.threads.virtual.enabled=true

With this enabled, Tomcat serves each request on a virtual thread, dramatically improving throughput for I/O-heavy endpoints without any code changes.

Pitfalls to Watch For

Pinning: Using synchronized blocks around blocking calls can pin a virtual thread to its carrier. Prefer ReentrantLock instead.
Thread pools: Don't pool virtual threads—they're cheap to create. Use newVirtualThreadPerTaskExecutor().
ThreadLocals: Be cautious with heavy ThreadLocal usage since you may now have millions of threads.

Conclusion

Virtual threads let Java developers write simple, synchronous code that scales to massive concurrency levels. Combined with framework support in Spring Boot, they offer a compelling alternative to reactive programming for many use cases. If you're on Java 21 or later, it's time to give them a try.

Spring AI + Gemini: Add Google's Models to Your Spring Boot App Without Rewriting Anything

Said Olano — Sat, 01 Aug 2026 14:49:41 +0000

Most "add an LLM to your backend" tutorials end with a pile of hand-rolled HTTP clients, JSON mapping, and retry logic that rots the moment the provider changes a field. Spring AI takes a different bet: treat a model the same way Spring already treats a datasource or a message broker — a bean you configure with properties and inject where you need it. Here's how that plays out with Google's Gemini, and the two setup traps that cost people an afternoon.

One starter, two ways to authenticate

As of 2026 the module you want is the Google GenAI starter. It's the one that supports both the free Gemini Developer API (just an API key) and the paid Vertex AI path (GCP credentials) — same code, different config.

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-google-genai</artifactId>
</dependency>

Pair it with the Spring AI BOM in your pom.xml so you don't have to pin the version by hand. For the free tier, grab a key at aistudio.google.com/apikey (Google account only, no card) and configure just the key:

spring:
  ai:
    google:
      genai:
        api-key: ${GEMINI_API_KEY}
        chat:
          model: gemini-2.5-flash
          temperature: 0.7

For Vertex AI instead, drop the API key and give it a project and location — Spring AI discovers your gcloud application-default credentials automatically, so you write zero auth code:

spring:
  ai:
    google:
      genai:
        project-id: your-gcp-project
        location: us-central1
        chat:
          model: gemini-2.5-flash

The actual call is boring — which is the point

The starter auto-configures a ChatClient.Builder. Inject it, build once, and the calling code looks identical to what you'd write for OpenAI or Anthropic:

@Service
public class GeminiService {

    private final ChatClient chatClient;

    public GeminiService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String ask(String message) {
        return chatClient.prompt()
                .user(message)
                .call()
                .content();
    }
}

Swapping providers later means changing the dependency and the config block — not this service. That's the whole value proposition: the model becomes a replaceable detail, not a hard dependency threaded through your codebase.

Structured output instead of string-scraping

The part that saves real time in a backend is mapping the model's answer straight onto a Java type, so you're not regex-ing prose:

public record Summary(String headline, List<String> keyPoints) {}

public Summary summarize(String article) {
    return chatClient.prompt()
            .user(u -> u.text("Summarize this: {doc}").param("doc", article))
            .call()
            .entity(Summary.class);
}

Spring AI generates the schema, asks Gemini to conform, and deserializes the response into your record. From here it's a short hop to tool calling and RAG — same ChatClient, a few more builder methods.

Two traps that look like bugs but aren't

Model deprecation. gemini-2.0-flash is deprecated and being shut down — Gemini 1.x identifiers already return 404. Use gemini-2.5-flash. A limit: 0 quota error usually means the model itself lost free-tier capacity, not that your account is throttled.

Auth-mode bleed. If you set project-id or location anywhere — even left over from an experiment — the client silently switches to Vertex AI mode and your free Developer API key gets rejected with a 400 that reads like a quota problem. For the free tier, set only the API key and delete every trace of project/location.

Both of these have burned people who assumed their key was bad when the config was the real culprit.

Wrap-up

The Spring AI abstraction earns its keep the day you swap Gemini for another model and touch nothing but a dependency and a YAML block. Getting there costs one starter, a few properties, and remembering that project-id is a mode switch, not just metadata.

Are you leaning toward the free Developer API for prototyping, or going straight to Vertex AI so prod and dev share one code path? What tipped the decision for you?

Context Engineering: Structuring Knowledge for Intelligent Systems

Said Olano — Sat, 18 Jul 2026 15:00:13 +0000

Context Engineering: Structuring Knowledge for Intelligent Systems

The Evolution of Context in AI

Context Engineering has emerged as a critical discipline in modern AI systems. Gone are the days when isolated models could solve complex problems. Today's most powerful AI applications rely on sophisticated context management—the art and science of structuring, organizing, and presenting information to maximize model understanding and decision-making.

Understanding Context Fundamentals

At its core, Context Engineering is about translating human understanding into machine-readable formats. This involves identifying what information matters, how it relates to other information, and how to present it most effectively.

Modern AI systems perform better when context is well-structured. Context Engineering addresses three critical dimensions: information relevance, hierarchical organization, and temporal awareness.

Practical Context Engineering Strategies

Organizations implementing Context Engineering typically focus on several key areas. Knowledge graphs provide structured representations of domain information. Prompt engineering has proven revolutionary for large language models.

The way we frame questions and provide background information dramatically impacts output quality. Context windows have become a crucial constraint, making efficient context management essential.

Real-World Applications

Context Engineering powers some of today's most impressive AI applications. In customer service, maintaining conversation context allows chatbots to provide coherent, personalized responses. In medical AI, proper contextualization improves diagnostic accuracy.

Future of Context Engineering

The field is evolving rapidly. Emerging trends include multimodal context, adaptive context, and federated context. As AI systems become more sophisticated, the ability to engineer context effectively becomes a competitive advantage.

Conclusion

Context Engineering bridges the gap between human knowledge and machine understanding. Organizations that master this discipline will build more capable, reliable, and user-friendly AI systems.

LLMs: From Transformers to Production-Ready Language Models

Said Olano — Sat, 18 Jul 2026 14:41:12 +0000

LLMs: From Transformers to Production-Ready Language Models

The Evolution of Language Models

Large Language Models (LLMs) have revolutionized how we approach Natural Language Processing. What started with transformer architectures has evolved into powerful systems that can understand, generate, and reason about text in ways that closely mimic human cognition.

Understanding the Core Architecture

At their heart, LLMs rely on the transformer architecture. This architecture uses self-attention mechanisms to process tokens in parallel, enabling both efficiency and effectiveness.

Modern LLMs stack multiple transformer layers, each with attention heads that learn different aspects of language.

From Research to Production

Deploying LLMs in production requires more than just a trained model. You need infrastructure, prompt engineering, evaluation frameworks, and safety guardrails.

Real-World Use Cases

LLMs power chatbots, code generation, and analysis. The key is understanding your use case and optimizing accordingly.

Conclusion

LLMs are powerful tools requiring thoughtful engineering, careful evaluation, and continuous refinement to deliver real value in production systems.