Java Code Geeks

MCP Logging in Spring AI

Yatin Batra — Thu, 22 Oct 2026 16:35:49 +0000

MCP Logging in Spring AI

The Model Context Protocol (MCP) lets an AI application call out to external tools and data sources through a standard client-server interface. When a tool runs on the server, the client usually only sees the final result — which makes it hard to know what happened in between: which step the server reached, what branch it took, or why it took so long. MCP solves this with a built-in logging capability: the server can stream log messages to the client while a tool is executing, independent of the tool’s actual return value. Spring AI’s MCP support exposes this capability on both the server and client side with just a few lines of code. This guide covers what MCP and MCP logging are, then walks through one complete example of a server that logs tool execution and a client that consumes those logs.

1. What Is MCP? What Is MCP Logging?

MCP (Model Context Protocol) is an open protocol that standardizes how an AI application (the client) talks to external systems (the server) that expose tools, resources, and prompts. Instead of writing a bespoke integration for every tool, both sides speak the same protocol — the client discovers what the server offers and invokes it in a uniform way, over transports like stdio or HTTP/SSE. MCP logging is one of the optional capabilities a server can declare. Once enabled, the server can send notifications/message events to the client at any point — before, during, or after a tool call — each carrying a severity level (debug, info, notice, warning, error, critical, alert, emergency), a logger name, and a message. The client can also call logging/setLevel to tell the server the minimum severity it wants to receive, filtering out noise like debug messages in production.

Logging is separate from the tool’s return value — it’s for observability, not for passing data back to the model.
It’s capability-based — a server only sends log notifications if it declared logging support during initialization.
It’s level-filtered — the client controls the noise floor via setLoggingLevel(...).

2. Code Example

The example below has two parts: an MCP server that exposes a single weather tool and emits log notifications while handling it, and an MCP client that subscribes to those logs and calls the tool.

2.1 Dependencies and Configuration

Spring AI ships separate starters for the MCP server and MCP client; the server also needs the logging capability turned on explicitly in configuration.

<!-- server -->
<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>
</dependency>

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

# application.properties (server)
spring.ai.mcp.server.name=weather-server
spring.ai.mcp.server.version=1.0.0
spring.ai.mcp.server.capabilities.logging=true

The spring-ai-starter-mcp-server-webmvc starter auto-configures an MCP server over HTTP/SSE, while spring.ai.mcp.server.capabilities.logging=true is what actually advertises the logging capability to connecting clients — without it, calls to exchange.loggingNotification(...) on the server are simply ignored.

2.2 Server: Tool That Emits Log Notifications

A regular @Tool-annotated method can accept an McpSyncServerExchange parameter, which Spring AI injects automatically and which is used to push log messages back to the client while the tool runs.

package com.example.mcp;

import org.springframework.ai.tool.annotation.Tool;
import org.springframework.stereotype.Service;

import io.modelcontextprotocol.server.McpSyncServerExchange;
import io.modelcontextprotocol.spec.McpSchema.LoggingLevel;
import io.modelcontextprotocol.spec.McpSchema.LoggingMessageNotification;

@Service
public class WeatherTools {

    @Tool(description = "Get the current weather for a city")
    public String getWeather(String city, McpSyncServerExchange exchange) {
        exchange.loggingNotification(LoggingMessageNotification.builder()
                .level(LoggingLevel.DEBUG)
                .logger("weather-tool")
                .data("Received weather request for city: " + city)
                .build());

        String result = lookupWeather(city);

        exchange.loggingNotification(LoggingMessageNotification.builder()
                .level(LoggingLevel.INFO)
                .logger("weather-tool")
                .data("Weather lookup completed for city: " + city)
                .build());

        return result;
    }

    private String lookupWeather(String city) {
        return "Sunny, 25°C in " + city;
    }
}

WeatherTools is a complete, self-contained @Service class: the imports pull in @Tool and @Service from Spring AI, plus McpSyncServerExchange, LoggingLevel, and LoggingMessageNotification from the MCP Java SDK that the method actually uses. Inside getWeather, each call to exchange.loggingNotification(...) builds a LoggingMessageNotification with a severity level, a logger name used to identify the source, and a free-text message, then sends it to the client immediately — the first notification fires before the lookup happens and the second fires right after, giving the client visibility into both the start and the end of the operation without changing what getWeather returns.

2.3 Server: Registering the Tool

The MCP server auto-configuration discovers tools through a ToolCallbackProvider bean, so WeatherTools needs to be wrapped and exposed that way.

package com.example.mcp;

import org.springframework.ai.tool.ToolCallbackProvider;
import org.springframework.ai.tool.method.MethodToolCallbackProvider;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class McpServerConfig {

    @Bean
    public ToolCallbackProvider weatherTools(WeatherTools weatherTools) {
        return MethodToolCallbackProvider.builder()
                .toolObjects(weatherTools)
                .build();
    }
}

McpServerConfig is a standalone @Configuration class whose imports bring in just the four Spring types the weatherTools bean needs: @Configuration and @Bean to declare the bean, plus ToolCallbackProvider and MethodToolCallbackProvider to build it. MethodToolCallbackProvider scans the given object (here, the WeatherTools bean injected as a method parameter) for @Tool-annotated methods and publishes them as callbacks the MCP server can list and invoke; this is the same mechanism Spring AI uses to expose tools to a chat model, reused here to expose them over MCP.

2.4 Client: Consuming Log Notifications

On the client side, a loggingConsumer is registered when building the McpSyncClient, and setLoggingLevel(...) sets the minimum severity the server should send.

package com.example.mcp;

import java.util.Map;

import io.modelcontextprotocol.client.McpClient;
import io.modelcontextprotocol.client.McpSyncClient;
import io.modelcontextprotocol.client.transport.HttpClientSseClientTransport;
import io.modelcontextprotocol.spec.McpSchema.CallToolRequest;
import io.modelcontextprotocol.spec.McpSchema.CallToolResult;
import io.modelcontextprotocol.spec.McpSchema.LoggingLevel;

public class WeatherClient {

    public static void main(String[] args) {
        var transport = HttpClientSseClientTransport.builder("http://localhost:8080").build();

        McpSyncClient client = McpClient.sync(transport)
                .loggingConsumer(notification ->
                        System.out.printf("[%s] %s: %s%n",
                                notification.level(), notification.logger(), notification.data()))
                .build();

        client.initialize();
        client.setLoggingLevel(LoggingLevel.DEBUG);

        CallToolResult result = client.callTool(
                new CallToolRequest("getWeather", Map.of("city", "Paris")));

        System.out.println("Tool result: " + result.content());
    }
}

WeatherClient is a runnable class with a main method, importing McpClient/McpSyncClient and HttpClientSseClientTransport to connect to the server, and CallToolRequest/CallToolResult/LoggingLevel to invoke the tool and read its result. Inside main, the loggingConsumer lambda runs once per notification the server sends, so both the DEBUG and INFO messages from WeatherTools are printed as they arrive; calling setLoggingLevel(LoggingLevel.DEBUG) tells the server not to filter anything out, while callTool(...) triggers the actual tool execution that produces those log notifications in the first place.

2.5 Output

Running WeatherClient.main against the server above calls the getWeather tool for “Paris” and prints the following, in order:

[DEBUG] weather-tool: Received weather request for city: Paris
[INFO] weather-tool: Weather lookup completed for city: Paris
Tool result: Sunny, 25°C in Paris

The two [DEBUG]/[INFO] lines come from the loggingConsumer firing as each exchange.loggingNotification(...) call arrives from WeatherTools, and they both print before the final Tool result line — proof that the log notifications travel to the client while getWeather is still running, not after callTool(...) returns.

3. Conclusion

MCP logging gives tool servers a dedicated, level-filtered channel for reporting what’s happening during execution, without overloading the tool’s actual return value. In Spring AI, enabling it is mostly configuration — spring.ai.mcp.server.capabilities.logging=true on the server — plus a couple of exchange.loggingNotification(...) calls inside a tool and a loggingConsumer on the client. For anything beyond trivial tools, this is a cheap way to get real observability into what a remote tool is doing while it runs.

Tags

A Guide to Structured Output in Spring AI

Yatin Batra — Thu, 22 Oct 2026 15:50:06 +0000

Enterprise Java

A Guide to Structured Output in Spring AI

Large Language Models (LLMs) naturally respond with free-form text. That’s great for a chat interface, but most applications need to feed the model’s answer into the rest of the system — save it to a database, pass it to another service, render it in a form. For that, we need predictable, structured data instead of a paragraph of prose. Spring AI solves this with its structured output support. It lets us ask a model to return data that is automatically converted into a Java object, a List, a Map, or any custom type we define — no manual string parsing required. In this guide, we’ll look at what structured output is and then walk through several ways to use it: converting responses into a domain entity, a list, a map, doing the conversion manually with ChatModel, and finally writing our own custom converter.

1. What Is Structured Output?

Structured output in Spring AI is built around the StructuredOutputConverter<T> interface. A converter does two things:

Provides a format instruction — a piece of text telling the model exactly how to format its answer (e.g., “respond only with JSON matching this schema”).
Converts the raw text response — once the model replies, the converter parses that string into the target Java type.

Spring AI ships with ready-made converters:

BeanOutputConverter<T> — converts JSON into a POJO.
ListOutputConverter — converts a comma-separated response into a List<String>.
MapOutputConverter — converts JSON into a Map<String, Object>.

When using the high-level ChatClient, we usually don’t even touch these converters directly — calling .entity(SomeType.class) picks the right one for us automatically. When we need more control, or we use the lower-level ChatModel API, we can apply a converter manually.

2. Code Example

Rather than five disconnected snippets, here is one complete, runnable Spring Boot application. It exposes five endpoints — one per technique — all sharing the same ActorFilms entity and the same injected ChatClient/ChatModel beans.

2.1 Dependency and Configuration

Before any of the conversion techniques can be used, the project needs the Spring AI OpenAI starter on the classpath along with an API key. The starter auto-configures the ChatClient.Builder and ChatModel beans used throughout the rest of this example.

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

# application.properties
spring.ai.openai.api-key=${OPENAI_API_KEY}
spring.ai.openai.chat.options.model=gpt-4o-mini

The pom.xml entry pulls in Spring AI’s OpenAI integration, while application.properties supplies the API key (read from an environment variable so it’s never hard-coded) and selects gpt-4o-mini as the chat model; together these are the only setup required before injecting ChatClient or ChatModel into any service.

2.2 Domain Entity

The ActorFilms record is the single domain type shared by every conversion technique below — it models an actor and the list of movie titles the model should return.

public record ActorFilms(String actor, List<String> movies) {}

Because ActorFilms is a plain Java record with two typed fields, Spring AI can derive a JSON schema from it automatically and reuse that same schema across the entity, manual, and custom-converter endpoints further down.

2.3 Custom Output Converter

Not every response fits neatly into JSON — a plain comma-separated line is sometimes easier for a model to produce reliably. UpperCaseListConverter implements StructuredOutputConverter<List<String>> to handle that case, and is used later by the custom-converter endpoint.

public class UpperCaseListConverter implements StructuredOutputConverter<List<String>> {

    @Override
    public List<String> convert(String text) {
        return Arrays.stream(text.trim().split("\\s*,\\s*"))
                .map(String::toUpperCase)
                .toList();
    }

    @Override
    public String getFormat() {
        return """
                Respond only with a comma separated list of items.
                Do not number them, and do not add any explanation or preamble.
                """;
    }
}

getFormat() supplies the instruction injected into the prompt, telling the model to reply with a bare comma-separated list, while convert() implements the matching parsing logic — splitting on commas and upper-casing each item — giving full control over both the request format and the response parsing.

2.4 Service — All Five Techniques in One Class

All five structured-output techniques live in a single FilmographyService, each exposed as its own method so they can be compared side by side.

@Service
public class FilmographyService {

    private final ChatClient chatClient;
    private final ChatModel chatModel;

    public FilmographyService(ChatClient.Builder builder, ChatModel chatModel) {
        this.chatClient = builder.build();
        this.chatModel = chatModel;
    }

    // 1. Converting the response into our domain entity
    public ActorFilms getFilmographyAsEntity(String actor) {
        return chatClient.prompt()
                .user("Generate the filmography of 5 movies for %s.".formatted(actor))
                .call()
                .entity(ActorFilms.class);
    }

    // 2. Converting the response into a List
    public List<String> getFilmographyAsList(String actor) {
        return chatClient.prompt()
                .user("List the titles of 5 movies starring %s.".formatted(actor))
                .call()
                .entity(new ParameterizedTypeReference<List<String>>() {});
    }

    // 3. Converting the response into a Map
    public Map<String, Object> getFilmographyAsMap(String actor) {
        return chatClient.prompt()
                .user("""
                        Give the debut movie year and total movie count for %s.
                        Return as a JSON map with keys "debutYear" and "movieCount".
                        """.formatted(actor))
                .call()
                .entity(new ParameterizedTypeReference<Map<String, Object>>() {});
    }

    // 4. Converting the response manually using ChatModel
    public ActorFilms getFilmographyManually(String actor) {
        BeanOutputConverter<ActorFilms> converter =
                new BeanOutputConverter<>(ActorFilms.class);

        String template = """
                Generate the filmography of 5 movies for {actor}.
                {format}
                """;

        Prompt prompt = new PromptTemplate(template, Map.of(
                "actor", actor,
                "format", converter.getFormat()
        )).create();

        Generation generation = chatModel.call(prompt).getResult();
        return converter.convert(generation.getOutput().getText());
    }

    // 5. Using a custom output converter
    public List<String> getFilmographyUpperCase(String actor) {
        UpperCaseListConverter converter = new UpperCaseListConverter();

        String template = """
                List 5 movie titles starring {actor}.
                {format}
                """;

        Prompt prompt = new PromptTemplate(template, Map.of(
                "actor", actor,
                "format", converter.getFormat()
        )).create();

        Generation generation = chatModel.call(prompt).getResult();
        return converter.convert(generation.getOutput().getText());
    }
}

Methods 1–3 go through ChatClient, using .entity(ActorFilms.class) and ParameterizedTypeReference to get a typed object, a list, and a map respectively; method 4 drops to the lower-level ChatModel and applies a BeanOutputConverter by hand; method 5 swaps that for the UpperCaseListConverter defined above — the same request/response flow, just with a different converter plugged in.

2.5 Controller

A thin FilmographyController exposes each service method as its own REST endpoint so every technique can be tested independently.

@RestController
@RequestMapping("/filmography")
public class FilmographyController {

    private final FilmographyService service;

    public FilmographyController(FilmographyService service) {
        this.service = service;
    }

    @GetMapping("/{actor}/entity")
    public ActorFilms entity(@PathVariable String actor) {
        return service.getFilmographyAsEntity(actor);
    }

    @GetMapping("/{actor}/list")
    public List<String> list(@PathVariable String actor) {
        return service.getFilmographyAsList(actor);
    }

    @GetMapping("/{actor}/map")
    public Map<String, Object> map(@PathVariable String actor) {
        return service.getFilmographyAsMap(actor);
    }

    @GetMapping("/{actor}/manual")
    public ActorFilms manual(@PathVariable String actor) {
        return service.getFilmographyManually(actor);
    }

    @GetMapping("/{actor}/custom")
    public List<String> custom(@PathVariable String actor) {
        return service.getFilmographyUpperCase(actor);
    }
}

2.6 Main Class

Finally, a standard Spring Boot entry point wires everything together and starts the embedded server.

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

@SpringBootApplication triggers auto-configuration for the Spring AI starter and the ChatClient.Builder / ChatModel beans, so no wiring beyond what’s already in application.properties is needed to run any of the five endpoints.

2.7 Code Run and output

With the API key exported, the application can be started and each endpoint exercised with a simple curl command.

export OPENAI_API_KEY=sk-...
mvn spring-boot:run

curl http://localhost:8080/filmography/Tom%20Hanks/entity
curl http://localhost:8080/filmography/Tom%20Hanks/list
curl http://localhost:8080/filmography/Tom%20Hanks/map
curl http://localhost:8080/filmography/Tom%20Hanks/manual
curl http://localhost:8080/filmography/Tom%20Hanks/custom

Each curl call hits one of the five endpoints on FilmographyController, letting all five structured-output techniques be verified independently against the same running instance of the application. Running them against the actor “Tom Hanks” produces the following JSON responses, one per technique:

GET /filmography/Tom%20Hanks/entity
{"actor":"Tom Hanks","movies":["Forrest Gump","Cast Away","Big","Toy Story","Saving Private Ryan"]}

GET /filmography/Tom%20Hanks/list
["Forrest Gump","Cast Away","Big","Toy Story","Saving Private Ryan"]

GET /filmography/Tom%20Hanks/map
{"debutYear":1980,"movieCount":5}

GET /filmography/Tom%20Hanks/manual
{"actor":"Tom Hanks","movies":["Forrest Gump","Cast Away","Big","Toy Story","Saving Private Ryan"]}

GET /filmography/Tom%20Hanks/custom
["FORREST GUMP","CAST AWAY","BIG","TOY STORY","SAVING PRIVATE RYAN"]

4. Conclusion

Structured output is what turns an LLM from a text generator into a reliable component of a Java application. With ChatClient.entity(...), converting responses into domain objects, lists, or maps takes a single method call. When we need more control — using ChatModel directly, or applying custom parsing logic — the StructuredOutputConverter interface gives us the same guarantees with full flexibility.

Tags

The Economics of Flaky Tests: What They Really Cost a Team

Eleftheria Drosopoulou — Thu, 22 Oct 2026 15:39:00 +0000

Software Development

The Economics of Flaky Tests: What They Really Cost a Team

A flaky test rarely breaks production. Instead, it quietly taxes every pull request your team opens.

The Hidden Tax

Every team knows the moment. A build turns red, someone shrugs, and the pipeline is simply run again. It passes, and everyone moves on. That small shrug is where the money leaks away, because each rerun costs minutes of waiting, a context switch, and a little more distrust in the suite.

This article puts numbers on that tax. First, we look at what published research says. Then we use simple math to show why even tiny flake rates matter at scale.

What the Research Actually Says

Google’s Numbers

In a May 2016 post on the Google Testing Blog, Google reported that about 1.5% of all its test runs show a flaky result, meaning the same code both passed and failed. It also found that almost 16% of its tests have some level of flakiness. In the post’s own example, a flaky rate of 1.5% means that about 15 tests will likely fail in a batch of 1,000, and each failure needs investigation by a build cop or developer.

One caution is worth making here. You may have seen the “16%” quoted as the share of developer time lost to flaky tests. That reading is wrong. The 16% describes the share of tests with some flakiness, not time. Please check any article that repeats it as a time figure.

What Causes Them

Next, why do tests flake? A well-known study by Luo, Hariri, Eloussi and Marinov, An Empirical Analysis of Flaky Tests (FSE 2014), examined 201 fixes in open-source projects. Its top three categories are shown below. As co-author Lamyaa Eloussi summarised on the Salesforce engineering blog, they cover most of the cases.

Cause	Share of fixes	Typical remedy found in the study
Async wait	45%	54% were fixed by waiting for the result instead of sleeping
Concurrency	20%	Data races, atomicity bugs and deadlocks
Test order dependency	12%	74% were fixed by cleaning shared state
Everything else	23% (remainder)	Network, time, unordered collections, and more

In short, most flakes are bugs in the tests themselves. Consequently, they are fixable engineering work, not bad luck.

Why Small Rates Add Up Fast

Here is the part that surprises people. A suite passes only if every test passes. So if each test flakes with probability p, a suite of n tests is green with probability (1 – p) to the power n, when the code is correct. A quick check: a 0.05% flake rate across 100 tests gives a green run about 95% of the time.

Computed from the formula above. It assumes independent flakes, which is a simplification.

Look at the orange line. With a seemingly harmless 0.05% rate per test, a 2,000-test suite is green only about 37% of the time. Therefore, the bigger the suite, the more a tiny rate hurts.

A Simple Cost Model

Now let us turn those probabilities into hours. The assumptions below are mine, not measured data, so please replace them with your own numbers. I assumed 20 developers, 4 CI runs per developer per day, 230 working days, a 2,000-test suite, and 30 minutes lost for each false red build. I also assumed no automatic retry.

Illustrative model, not measured data. Hours lost = runs per year x chance of a false red x 0.5 hours.

Per-test flake rate	False red builds	Hours lost per year	Share of team capacity
0.001%	2% of runs	182	0.5%
0.005%	9.5% of runs	876	2.4%
0.01%	18.1% of runs	1,668	4.5%
0.02%	33.0% of runs	3,033	8.2%

Capacity here means 20 developers times 230 days times 8 hours, or 36,800 hours. Even the modest 0.01% row costs about 1,668 hours, or roughly 208 working days, every year.

The model also leaves out two costs that are harder to count. One is the cost of ignored failures, because people who expect a flake may dismiss a real bug. The other is infrastructure. A research paper from George Mason University, Root Causing Flaky Tests in a Large-Scale Industrial Setting, reports Google spending roughly 2 to 16% of its testing budget on reruns. It cites another source for that range, and I could not trace the original, so treat it as approximate.

What to Do About It

Google’s post describes the tools it uses: rerunning only failed tests, automatic reruns, and a tool that quarantines a test when its flakiness grows too high. A test can also be marked flaky, so that it must fail three times in a row before a failure is reported. These are good first aid. However, reruns hide the cost instead of removing it, so the real fix is to repair the cause.

Quick checklist

Measure first: record every rerun and tag each failure as real, flaky or unknown.
Quarantine proven flakes quickly, and file a ticket for each one.
Replace sleeps with waits for a condition.
Make every test create and clean its own data.
Run tests in random order now and then to expose hidden dependencies.

What We Have Learned

Flaky tests are a recurring tax, not a rare nuisance. Google reports about 1.5% of test runs as flaky and almost 16% of tests as touched by flakiness, and the 16% is a share of tests, not of time. Because a suite is green only when every test passes, a tiny per-test rate compounds quickly: at 0.05% per test, a 2,000-test suite is green about 37% of the time. In my illustrative model, a 0.01% rate costs a 20-person team around 1,668 hours a year. Since the best-known study traces most flakes to async waits, concurrency and test order, the cure is mostly better tests. So measure your own reruns, quarantine fast, and fix the cause.

Tags

[DEALS] Koofr Cloud Storage: Lifetime Subscription (1TB) (75% off) & Other Deals Up To 98% Off – Offers End Soon!

Java Code Geeks — Thu, 22 Oct 2026 10:30:30 +0000

Meta JCG

[DEALS] Koofr Cloud Storage: Lifetime Subscription (1TB) (75% off) & Other Deals Up To 98% Off – Offers End Soon!

Hello fellow geeks,

Fresh offers await you on our Deals store, please have a look!

Koofr Cloud Storage: Lifetime Subscription (1TB)
(75% off)

Ending soon // by Java Code Geeks

Access All of Your Files in One Place! Koofr Offers 1TB of Safe Cloud Storage to Secure Your Files

iScanner App: Lifetime Subscription (iPhone, iPad & Android)
(87% off)

iProVPN: 5-Year Subscription
(94% off)

Internxt Cloud Storage Lifetime Subscription: 10TB Plan
(90% off)

Headway Premium: Lifetime Subscription
(76% off)

Glooin Starter Plan: Lifetime Subscription
(74% off)

Microsoft Office 2024 Professional Plus for Windows: Lifetime License
(80% off)

Microsoft Visual Studio Professional 2026
(94% off)

Microsoft Windows 11 Pro
(92% off)

OysterVPN: VPN Lifetime Subscription
(85% off)

PCmover Business: Non-Expiring Licenses
(25% off)

Tags

BEAM Supervision Trees and “Let It Crash”: What Java Services Can Steal from Erlang

Eleftheria Drosopoulou — Thu, 22 Oct 2026 05:29:00 +0000

Core Java

BEAM Supervision Trees and “Let It Crash”: What Java Services Can Steal from Erlang

Most Java code tries hard to never fail. Erlang takes the opposite view, and the idea travels better than you might expect.

Where “Let It Crash” Comes From

The phrase sounds reckless at first. In practice, it is a careful design rule. Joe Armstrong, one of Erlang’s creators, laid it out in his December 2003 doctoral thesis, Making reliable distributed systems in the presence of software errors. The thesis has dedicated sections called “Let some other process fix the error” and “Let it crash”.

His reasoning is simple. We know how to survive hardware faults, because we can replicate. Software bugs are different. As Armstrong wrote on the Erlang mailing list, replicating faulty software just gives you two programs failing for the same reason. Therefore, the goal shifts from preventing every error to recovering from it quickly.

How a Supervision Tree Works

Workers and Supervisors

In OTP, the Erlang platform’s library set, processes are arranged in a tree. Workers do the real job, while supervisors only watch them and restart them when they die. Because the tree nests, a supervisor can itself be supervised.

Restart Strategies

The OTP design principles define the main strategies. The default is one_for_one.

Strategy	What happens when one child dies
one_for_one	Only that child is restarted (the default)
one_for_all	All children are restarted
rest_for_one	The failed child and those started after it are restarted

The Safety Valve

Restarting forever would only hide a real bug. For that reason, the supervisor manual defines a maximum restart intensity. If more than intensity restarts happen within period seconds, the supervisor terminates all its children and then itself. The defaults are 1 restart in 5 seconds. As a result, the failure climbs one level up the tree, where a wider restart can be attempted.

What Java Teams Can Borrow

Java does not have a built-in supervision tree, and its threads share one heap. Still, the ideas transfer in four useful ways.

First, keep the supervisor separate from the work. The code that restarts a task should not be the code that performs it. Second, always put a limit on restarts, as OTP does. Third, escalate when the limit is hit, instead of retrying silently. Finally, restart into a clean state, rather than patching a half-broken object.

You do not have to build this from scratch. Apache Pekko, the open-source fork of Akka, offers supervision for actors, and its fault tolerance guide shows a restart strategy limited to a number of retries within a time window. Note that in typed actors the default is to stop the actor after an exception, not restart it.

A Tiny Supervisor You Can Run

To see the idea clearly, I wrote a minimal version in plain Java with no libraries. It mirrors the OTP rule: give up when more than three crashes occur within one second. The worker handles 1,000 tasks, and it crashes on every Nth task. I tested it on JDK 21, and it needs JDK 11 or newer. Save it as Sup.java.

import java.util.ArrayDeque;
import java.util.concurrent.atomic.AtomicInteger;

public class Sup {
    static final AtomicInteger done = new AtomicInteger();

    // Like OTP: give up when more than maxRestarts crashes happen within windowMs.
    static int supervise(Runnable worker, int maxRestarts, long windowMs)
            throws InterruptedException {
        var crashes = new ArrayDeque<Long>();
        int restarts = 0;
        while (true) {
            Throwable[] failure = new Throwable[1];
            Thread t = new Thread(worker);
            t.setUncaughtExceptionHandler((th, ex) -> failure[0] = ex);
            t.start();
            t.join();
            if (failure[0] == null) return restarts;        // finished normally
            long now = System.currentTimeMillis();
            crashes.addLast(now);
            while (now - crashes.peekFirst() > windowMs) crashes.removeFirst();
            if (crashes.size() > maxRestarts) {
                throw new IllegalStateException("gave up after " + restarts + " restarts");
            }
            restarts++;
        }
    }

    static Runnable worker(int crashEvery, int total) {
        return () -> {
            int n;
            while ((n = done.incrementAndGet()) <= total) {
                try { Thread.sleep(2); } catch (InterruptedException e) { return; }
                if (n % crashEvery == 0) throw new RuntimeException("boom at task " + n);
            }
        };
    }

    public static void main(String[] args) throws Exception {
        for (int every : new int[] {25, 50, 100, 200, 400}) {
            done.set(0);
            String result;
            try {
                int r = supervise(worker(every, 1000), 3, 1000);
                result = "finished, restarts=" + r;
            } catch (IllegalStateException e) {
                result = e.getMessage();
            }
            System.out.println("crash every " + every + " tasks: " + result
                + ", tasks done=" + Math.min(done.get(), 1000));
        }
        // unsupervised: one thread, dies at first crash
        done.set(0);
        Thread t = new Thread(worker(400, 1000));
        t.setUncaughtExceptionHandler((th, ex) -> { });
        t.start(); t.join();
        System.out.println("unsupervised (crash every 400): tasks done=" + Math.min(done.get(), 1000));
    }
}

java Sup.java

I ran it twice and got identical output both times. Timing-based results can shift on a slower machine, so treat the exact crash counts as illustrative. First, an unsupervised worker that crashes every 400 tasks stops at task 400. With the supervisor, the same worker finishes all 1,000 tasks after two restarts.

Next, the safety valve matters. When the worker crashes often, the supervisor stops restarting and escalates instead of looping.

Both charts demonstrate the restart-limit behavior of this small program and are not benchmarks.

Crashing every 25, 50 or 100 tasks hit the limit after three restarts, so the supervisor gave up. Crashing every 200 or 400 tasks stayed under the limit, and the work completed.

Where the Analogy Breaks

Topic	Erlang/BEAM	Typical Java service
Failure isolation	Processes are isolated and share nothing	Threads share one heap
Restart cost	Restarting a process is part of the design	You must build and test it yourself
Bad state	Dies with the process	Can leak into shared objects

Moreover, a restart cannot fix a bug that fails the same way every time. It only buys you recovery from transient faults, which is why the limit exists. Also, “let it crash” never means skipping input validation at the system boundary.

Quick checklist

Separate the code that supervises from the code that works.
Cap restarts per time window, and escalate when the cap is hit.
Restart into clean state, not into a half-damaged object.
Make restarted work idempotent, so a retry does no harm.
Still validate input at the boundary.

What We Have Learned

Armstrong’s 2003 thesis argued that software errors cannot be replicated away, so systems should recover instead. OTP puts this into supervision trees, where supervisors restart workers under strategies such as one_for_one, one_for_all and rest_for_one. A restart limit, which defaults to 1 restart in 5 seconds, makes a supervisor escalate rather than loop forever. Java lacks a built-in tree, but the habits carry over, and Pekko offers a ready-made version. My small supervisor showed both sides: a worker that crashed every 400 tasks finished all 1,000 under supervision, while a worker that crashed too often triggered the safety valve. In short, supervise separately, limit restarts, and escalate.

Tags

Strings and Unicode: UTF-16, Compact Strings, and Why Emoji Break charAt

Eleftheria Drosopoulou — Wed, 21 Oct 2026 16:15:00 +0000

Core Java

Strings and Unicode: UTF-16, Compact Strings, and Why Emoji Break charAt

Java says a string has two characters, while your user sees exactly one. Both answers are correct, and that is the trap.

The Bug Behind a Single Smiley

Imagine a form that limits a nickname to ten characters. A user types ten emoji, yet your code rejects the input as too long. Alternatively, a truncation routine cuts a status message and leaves a broken symbol at the end. Both bugs share one cause, and understanding it takes only a few minutes.

What a Java String Really Stores

Chars Are 16-Bit Units

A Java char is a 16-bit unit, but Unicode defines far more than 65,536 code points. Therefore, anything beyond that range, including most emoji, is stored as two chars called a surrogate pair. Methods such as length() and charAt() count these units, not what a person would call a character.

Three Different Answers to “How Long?”

To make this concrete, I ran a small program on JDK 21 and counted the same strings in three ways. The flag and the family emoji are the interesting rows. The family is five code points glued together with zero-width joiners, yet it renders as one symbol.

As the chart shows, plain text agrees across all three counts. However, the moment emoji appear, the numbers drift apart. The Unicode term for what users perceive is a grapheme cluster, defined in Unicode Standard Annex #29.

A Short Program You Can Run

The code below needs JDK 11 or newer to launch as a single file, and I tested it on JDK 21. I wrote the emoji as escape sequences, so it works whatever your terminal or file encoding is.

import java.util.regex.Pattern;

public class Emoji {
    public static void main(String[] args) {
        String smile = "\uD83D\uDE00";   // one emoji, U+1F600
        System.out.println("length     = " + smile.length());
        System.out.println("codePoints = " + smile.codePointCount(0, smile.length()));
        System.out.printf("charAt(0)  = U+%04X%n", (int) smile.charAt(0));
        System.out.printf("codePointAt(0) = U+%X%n", smile.codePointAt(0));

        String family = "\uD83D\uDC68\u200D\uD83D\uDC69\u200D\uD83D\uDC67";
        long graphemes = Pattern.compile("\\X").matcher(family).results().count();
        System.out.println("family length = " + family.length());
        System.out.println("family code points = " + family.codePoints().count());
        System.out.println("family graphemes   = " + graphemes);
    }
}

java Emoji.java

Expected output: a length of 2, one code point, and charAt(0) returning U+D83D. That value is only half of the emoji, a lone high surrogate. For the family, you get 8 units, 5 code points, and 1 grapheme. The regex \X matches one extended grapheme cluster, so counting its matches gives the user-visible length.

Compact Strings: Same API, Smaller Memory

Next comes the part that surprises many developers. Since JDK 9, JEP 254 changed the internal storage from a char array to a byte array plus an encoding flag. According to the JDK 9 release notes, a string is stored either as Latin-1 (one byte per character) or as UTF-16 (two bytes per character), depending on its content. The JEP explicitly says that using UTF-8 internally was not a goal.

Importantly, the public API did not change. charAt() still returns UTF-16 units, so the emoji problem above is identical on every modern JDK.

One Character Can Double a String

Here the trade-off becomes visible. I read the backing array of four 1,000-character strings through reflection, using --add-opens on my own machine. This is internal detail, not something to ship in production code.

Both charts come from my own runs on OpenJDK 21. They are single-machine measurements of string layout, not performance benchmarks.

A single non-Latin-1 character switches the whole string to two bytes per character. Consequently, text that is almost entirely English but contains one emoji costs twice as much memory. For completeness, starting the JVM with -XX:-CompactStrings made even the plain ASCII and Latin-1 strings use 2,000 bytes in my run.

Internal form	Bytes per char	Used when
Latin-1	1	Every character is U+00FF or lower
UTF-16	2	Any character is above U+00FF

Choosing the Right Tool

Your question	Use this
How many UTF-16 units?	`length()`
How many Unicode code points?	`codePointCount()` or `codePoints()`
How many characters does the user see?	Grapheme clusters, for example regex `\X`
How many bytes on the wire?	`getBytes(StandardCharsets.UTF_8)`

Quick checklist

Never assume one char equals one character.
Do not cut a string at an arbitrary index, since you may split a surrogate pair.
Validate user-facing limits by grapheme count, and storage limits by bytes.
Remember that one emoji can double a mostly Latin-1 string in memory.
Test with emoji, flags, and accented text, not only ASCII.

What We Have Learned

A Java string is a sequence of 16-bit UTF-16 units, so emoji and other supplementary characters occupy two of them. That is why charAt can return half of a character and length can disagree with what users see. Code points fix the first problem, and grapheme clusters fix the second, as the family emoji (8 units, 5 code points, 1 grapheme) showed. Meanwhile, compact strings, introduced in JDK 9, store Latin-1 text in one byte per character without changing the API, although one wider character doubles the whole string. As a result, choose your counting method by the question you are asking, and test with emoji early.

Tags

[FREE EBOOKS] No One Works Here, Rapid Reculturing & Four More Best Selling Titles

Java Code Geeks — Wed, 21 Oct 2026 10:30:30 +0000

Meta JCG

[FREE EBOOKS] No One Works Here, Rapid Reculturing & Four More Best Selling Titles

Hello fellow geeks,

Fresh offers await you on our Information Technology Research Library, please have a look!

	No One Works Here: How AI-Driven Enterprises Are Raising the Bar for Business, Leadership, and Competition ($30.00 Value) FREE for a Limited Time USA TODAY BESTSELLER. The first signs of corporate collapse rarely appear in balance sheets. They appear in latency. They appear in hiring delays, in meetings that solve nothing, and in the weeks it takes to make a decision that a machine could have made in seconds. For the last century, business moved at the speed of human cognition. We gathered data, deliberated, and executed. That cycle took quarters. Today, AI has compressed that cycle to hours. Historically, organizational design has always accounted for latency, but only within the constraints of a human-centric hierarchy. Today, the fundamental unit of the enterprise has changed. An organization is no longer just a collection of people; it is a complex network of nodes, some human, some autonomous AI agents. To build for this reality, traditional management theory must be re-evaluated. We must now look to system architecture and human-computer interaction, hardwiring their rigorous principles of latency and data flow directly into organizational design. In No One Works Here, Paul Cheek, MIT Senior Lecturer, software engineer, and entrepreneur, delivers a provocative and urgent roadmap for the post-human organization. He argues that we are witnessing a fundamental shift in the physics of business: moving from an era where humans do the work to an era where humans design the intent. This book redefines how we think about the structure of work, the meaning of enterprise, and the future of capitalism itself. Similarly, it presents how incumbent organizations and economies have a new threat presented in the opportunity for underdog companies and economies to leapfrog them. It is both a visionary manifesto and a practical playbook for the AI era…one that reframes not only how we build organizations, but how we define them. This is not a book about mass unemployment. It is a manual for the greatest organizational design pivot since the Industrial Revolution. Inside, you will discover: The Latency Trap: Why the most dangerous metric in your company isn’t burn rate, it’s the time cost of human involvement. The New Operating System: How to build AI-Driven Enterprises that allow your organization to run, learn, and optimize while you sleep. From Operator to Architect: A tactical guide for leaders who need to stop working in their business so they can start programming it. The companies that thrive in this new age will be the ones that delegate cognitive work to intelligent systems. The ones that die will be the ones that insist on keeping a human in the loop for decisions that were obsolete yesterday. For companies competing on scale and speed, you are now on borrowed time from your last human-gated decision. This book is your guide to buying that time back. Get it FREE!
	Rapid Reculturing: Transforming Organizations at Pace and Scale ($30.00 Value) FREE for a Limited Time How can we lead for success in the age of AI? An answer to the leadership crisis facing today’s organizations. Rapid Reculturing: Transforming Organizations at Pace and Scale takes on one of the biggest issues facing today’s business world. To thrive in an AI-powered world, organizations need an entirely new approach. In this book, award-winning authors Alex Bailey and Kerri O’Neill offer a fresh, science-backed model for building sustainable high performance in the AI era. With traditional change models breaking down under the pressures of AI, diversity, five generations at work, and burnout rates skyrocketing, leaders urgently need a new playbook. If you’re looking for a shortcut to creating a culture that works in the Intelligence Age, this book is for you. It will ignite you to shed the practices that no longer serve us and respond to the demand for more human, adaptive leadership for a complex world. Lead culture change to support high performance in the complex, fast-paced “Intelligence Age”. Identify and replace leadership practices that are no longer effective in today’s world. Become more adaptive, so you and your organization can thrive amid ongoing change. Tackle employee burnout and high turnover, boosting productivity without sacrificing the people who make it happen. This book inspires a mindset shift in business leaders, HR professionals, and transformation consultants. With Re-Culturing Your Organization at Pace and Scale, you can ride the tide of AI-driven change and come out on top. Get it FREE!
	Strategic Approaches to Intrusion Detection in Cloud-IoT Ecosystem ($225.00 Value) FREE for a Limited Time Future-proof your digital infrastructure with this essential book, which provides a comprehensive exploration of both traditional and advanced machine and deep learning models to implement resilient and intelligent intrusion detection systems for securing complex cloud-IoT environments. The rapid growth of cloud computing and the Internet of Things has transformed industry by enabling real-time data collection, processing, and automation. However, this increasing interconnectivity also introduces significant security challenges, including data breaches, unauthorized access, and cyber threats. Ensuring the security and privacy of cloud-IoT environments requires advanced intrusion detection mechanisms, privacy-preserving strategies, and efficient resource management. This book explores various advanced methods to achieve these goals, including machine and deep learning models, to protect cloud-IoT systems against cyber threats. This book covers both traditional and advanced techniques to implement intrusion detection systems and provides detailed comparative analysis. By offering practical insights, readers will gain a deeper understanding of how to effectively implement intelligent security solutions, ensuring resilience, privacy, and protection against evolving cyber threats in cloud-IoT environments. Readers will find the volume: Provides comprehensive coverage of topics like machine and deep learning for intelligent security;. Explores cyber-IoT systems and intrusion detection systems for identifying suspicious activities and mitigating potential threats;. Discusses various security mechanisms to safeguard the cloud-IoT environment and implement various techniques to detect intrusions early on. Get it FREE!
	The New Rules of AI Search: SEO for visibility in ChatGPT, Google Gemini and Generative Search ($26.99 Value) FREE for a Limited Time Optimize your brand visibility for AI-powered search engines and large language models. In The New Rules of AI Search: SEO for visibility in ChatGPT, Google Gemini and Generative Search, Crystal Carter delivers a practical guide to optimizing brand visibility across AI-powered platforms. As large language models transform how consumers discover products and services, traditional SEO strategies require fundamental updates to remain effective in this new search paradigm. The New Rules of AI Search explores the technical and strategic dimensions of generative engine optimization. Crystal Carter examines how AI search platforms aggregate and present information differently than traditional search engines, providing actionable frameworks for ensuring your brand appears prominently when users query ChatGPT, Google Gemini, and similar platforms for recommendations and information. Readers will also discover: Specific techniques for structuring content that AI systems can easily understand, cite, and recommend to users seeking information. Strategies for building brand authority signals that large language models recognize and prioritize in their generated responses. Methods for monitoring and measuring your brand’s visibility across multiple AI search platforms and generative interfaces. Practical approaches for adapting existing SEO infrastructure to meet the unique requirements of AI-powered discovery channels. Frameworks for anticipating future developments in generative search and positioning your brand ahead of algorithmic changes. Essential for digital marketers, SEO professionals, brand managers, and business owners seeking to maintain competitive visibility, this guide provides the strategic foundation for succeeding as AI fundamentally transforms how consumers search for and discover information online. Offer Expires 10/27/2026. Get it FREE!
	10 Canva AI Features Every Creator Should Use in 2026 ($21 Value) FREE For a Limited Time Master the newest Canva tools, from AI video to branded emails, and save hours on content creation. The latest Canva release is packed with features that radically improve how creators work. Whether you’re designing visuals, launching campaigns, or building brands, these updates are built for speed and simplicity. This guide gives you a clear, no-fluff breakdown of the most useful tools added in 2026 – including AI-powered video, smart design assistants, and real-time publishing. In this book you will learn: How Canva’s Magic Video turns raw clips into ready-to-post edits. Why creators are using AI layouts to skip design blocks. How to launch branded email campaigns without leaving Canva. What Canva Grow offers for running full ad campaigns in one place. How to manage forms, brands, and data in one dashboard. If you’re a creator, marketer, or business owner using Canva, this is your shortcut to mastering the biggest update yet. Download now to upgrade your content workflow in minutes. Get it FREE!
	How to Build Your First Notion Dashboard in Minutes ($21 Value) FREE For a Limited Time Learn how to build a Notion dashboard that shows everything that matters in one place – – tasks, projects, quick capture and more. Perfect for beginners who think Notion is too complicated to set up. Most people think Notion is too complicated – – but a great dashboard isn’t about looking pretty, it’s about seeing everything that matters in one place without clicking around. This free guide shows you how to build your first command-centre dashboard in minutes. You’ll learn: How to set up a Home page that acts as your command centre. How to create a clean top section with your priority, date and focus. How to add a tasks database filtered to show only what’s due now. How to pull in active projects as a linked board view. How to add a quick-capture section for ideas and brain dumps. How to pin your dashboard and review it weekly so it evolves with your workflow. Whether you’re brand new to Notion or rebuilding your setup, you’ll finish with a single dashboard you check every morning instead of juggling tabs and sticky notes. To unlock all AI tutorials, visit CNTRAL.AI/TUTORIALS. Get it FREE!

That’s it for now, we hope you found them insightful. Stay tuned for more!

Till next time, keep geeking!

Tags

JFR Event Streaming: Continuous Production Profiling Without a Vendor Agent

Eleftheria Drosopoulou — Wed, 21 Oct 2026 05:02:00 +0000

Core Java

JFR Event Streaming: Continuous Production Profiling Without a Vendor Agent

Your JVM already ships with a profiler that is safe for production. Since JDK 14, it can also talk to you in real time.

Why You May Not Need an Agent

Many teams reach for a vendor agent the moment production slows down. However, the JDK has carried its own recorder for years. JEP 328 brought Flight Recorder into OpenJDK 11, according to Oracle’s Java Magazine. Until Java 14, though, it only produced files that you had to dump and open later.

That changed with JEP 349. It exposes JFR data for continuous monitoring, and the JEP notes that HotSpot emits more than 500 data points through JFR. As a result, you can react to events while the application is still running.

How Event Streaming Works

Inside the Same JVM

The entry point is RecordingStream in the jdk.jfr.consumer package. You enable the events you care about, register a handler, and start the stream. Each handler is simply a lambda that runs when an event arrives.

From Another Process

Streaming also works from outside. JEP 349 explains that the disk repository location is stored in the jdk.jfr.repository system property, which you can read through the attach API. In addition, RemoteRecordingStream in the jdk.management.jfr module lets a separate process consume events, as the Inside Java overview shows.

A Small Example You Can Run

The program below needs JDK 14 or newer (I ran it on JDK 21). Save it as Stream.java, then start it with the single command underneath. It prints CPU load every second and reports any lock wait longer than 10 ms.

import java.time.Duration;
import jdk.jfr.consumer.RecordingStream;

public class Stream {
    public static void main(String[] args) throws Exception {
        try (var rs = new RecordingStream()) {
            rs.enable("jdk.CPULoad").withPeriod(Duration.ofSeconds(1));
            rs.enable("jdk.JavaMonitorEnter")
              .withThreshold(Duration.ofMillis(10));
            rs.onEvent("jdk.CPULoad", e -> System.out.printf(
                "jvm user cpu: %.1f%%%n", e.getFloat("jvmUser") * 100));
            rs.onEvent("jdk.JavaMonitorEnter", e -> System.out.println(
                "lock wait: " + e.getDuration().toMillis() + " ms"));
            rs.startAsync();

            Object lock = new Object();
            Thread t = new Thread(() -> {
                synchronized (lock) {
                    try { Thread.sleep(300); } catch (Exception x) { }
                }
            });
            t.start();
            Thread.sleep(50);
            synchronized (lock) { }
            Thread.sleep(3000);
        }
    }
}

java Stream.java

On my machine it printed a lock wait of roughly 250 ms, followed by one CPU line per second. Your exact numbers will differ, naturally.

What Does It Cost?

Overhead is the question every operator asks first. The JDK answers it inside its own configuration files. The default setting is described as safe for continuous production use, typically under 1% overhead, while profile is described as typically around 2%. Notice that these are documented targets, not measurements from my workloads, so test your own service before trusting them.

Setting	Documented overhead	Intended use
default	Typically under 1%	Always-on production recording
profile	Typically around 2%	Short, focused investigations

The difference comes from how aggressively each setting collects data. I read both files from the JDK 21 installation on my machine. The profile setting simply halves every threshold, so it catches shorter waits and slower calls.

Similarly, profile samples twice as often. Converting the configured values into samples per second makes this easy to see.

One more caution applies here. According to the Inside Java overview, how you implement a stream can itself affect performance. Therefore, keep handlers short, and push heavy work onto another thread.

A Practical Production Setup

First, start the JVM with a rolling on-disk recording. Replace app.jar with your own application.

java -XX:StartFlightRecording:name=prod,settings=default,maxage=6h,disk=true -jar app.jar

Later, if something looks wrong, copy the recent data to a file with jcmd. The JVM prints this hint itself at startup. Replace <pid> with your process id.

jcmd <pid> JFR.dump name=prod filename=/tmp/prod.jfr

Quick checklist

Start with the default setting, never profile, for always-on use.
Enable only the events you actually read.
Keep stream handlers fast and non-blocking.
Set maxage so the disk repository stays bounded.
Measure overhead on your own workload first.

Streaming Versus Dump Files

Question	Event streaming	Dump file
When do you see data?	As events arrive	After you dump
Best for	Alerts and live metrics	Deep post-incident analysis
Extra tooling	A small consumer program	A viewer such as JDK Mission Control

To be fair, a vendor product still adds dashboards, long-term storage, and cross-service views that JFR does not provide on its own. Nevertheless, for many teams the built-in route covers the first and most urgent questions at no licence cost.

What We Have Learned

JFR has been part of OpenJDK since version 11, and JEP 349 added live event streaming in Java 14. A RecordingStream lets one JVM watch itself, while a remote stream and the disk repository allow outside consumers. The documented overhead is typically under 1% for the default setting and around 2% for profile, and profile simply samples twice as aggressively. Consequently, a rolling default recording plus a small stream consumer gives you continuous production insight without installing a vendor agent. Just measure on your own system, and keep your handlers light.

Tags

Mutation testing with PIT: why 100% coverage proves almost nothing

Eleftheria Drosopoulou — Tue, 20 Oct 2026 15:33:00 +0000

Core Java

Mutation testing with PIT: why 100% coverage proves almost nothing

PIT (also called Pitest) is the usual mutation testing tool for the JVM. It generates mutants for you, using a set of built-in mutators that cover things like boundary changes, negated conditions, arithmetic operators and return values. It plugs into Maven and Gradle, and its source lives in the project repository, whose latest release when I checked was 1.30.0.

Now for an honest note about this article. I could not run PIT itself. The sandbox I used for the measurements cannot reach Maven Central, where PIT’s jars are published, and the GitHub release only ships source code. So I did the next best thing: I wrote a small script that applies PIT-style changes by hand, one at a time, and runs the tests each time. The coverage numbers below come from real JaCoCo, but the mutation numbers are from my own harness. PIT would generate its own list of mutants, and its counts could differ from mine.

The experiment: 100% coverage, zero mutants killed

The code under test

I wrote a small shipping-cost rule, the kind of logic that lives in every e-commerce codebase. The base fee is 500 cents. Parcels over 1,000 grams pay 20 cents per extra 100 grams. Express doubles the cost. Orders of 10,000 cents or more ship free.

public class ShippingCost {
    private ShippingCost() { }

    public static int cents(int orderCents, int weightGrams, boolean express) {
        int cost = 500;
        if (weightGrams > 1000) {
            cost += (weightGrams - 1000) / 100 * 20;
        }
        if (express) {
            cost = cost * 2;
        }
        if (orderCents >= 10_000) {
            return 0;
        }
        return cost;
    }
}

Two test suites

The first suite is the kind many of us have written on a tired Friday. It touches every branch and asserts only that the answer is sane.

public class WeakTest {
    @Test public void lightStandard() { assertTrue(ShippingCost.cents(2000, 500, false) >= 0); }
    @Test public void heavyExpress()  { assertNotNull(ShippingCost.cents(2000, 2500, true)); }
    @Test public void bigOrder()      { assertTrue(ShippingCost.cents(20000, 500, false) >= 0); }
}

The second suite checks exact values, including the awkward edges of each rule.

public class StrongTest {
    @Test public void lightStandard()       { assertEquals(500,  ShippingCost.cents(2000, 500, false)); }
    @Test public void exactlyAtWeightLimit(){ assertEquals(500,  ShippingCost.cents(2000, 1000, false)); }
    @Test public void justOverWeightLimit() { assertEquals(520,  ShippingCost.cents(2000, 1100, false)); }
    @Test public void heavyExpress()        { assertEquals(1600, ShippingCost.cents(2000, 2500, true)); }
    @Test public void justBelowFreeLimit()  { assertEquals(500,  ShippingCost.cents(9999, 500, false)); }
    @Test public void exactlyAtFreeLimit()  { assertEquals(0,    ShippingCost.cents(10000, 500, false)); }
    @Test public void freeExpress()         { assertEquals(0,    ShippingCost.cents(20000, 500, true)); }
}

What coverage says

I ran each suite under JaCoCo 0.8.15 on JDK 25 (Temurin 25+36) with JUnit 4.13.2. Both suites pass, and both get the same report:

Metric	Weak suite	Strong suite
Instructions covered	28 of 28	28 of 28
Branches covered	6 of 6	6 of 6
Lines covered	8 of 8	8 of 8
Methods covered	1 of 1	1 of 1

Read that table again. By coverage alone, the two suites are identical. A dashboard would give both a gold star.

What mutation testing says

Next I applied twelve single-change mutants, one at a time, and ran both suites against each. Every mutant compiled cleanly, and I checked that each kill came from failing assertions, not from a build error.

#	Mutator style	Change	Weak suite	Strong suite
1	Conditional boundary	`weightGrams > 1000` to `>= 1000`	survived	survived
2	Negated conditional	`weightGrams > 1000` to `<= 1000`	survived	killed
3	Math	`weightGrams - 1000` to `+ 1000`	survived	killed
4	Math	`/ 100 * 20` to `* 100 * 20`	survived	killed
5	Math	`/ 100 * 20` to `/ 100 / 20`	survived	killed
6	Math	`cost +=` to `cost -=`	survived	killed
7	Negated conditional	`if (express)` to `if (!express)`	survived	killed
8	Math	`cost * 2` to `cost / 2`	survived	killed
9	Conditional boundary	`orderCents >= 10_000` to `>`	survived	killed
10	Negated conditional	`orderCents >= 10_000` to `<`	survived	killed
11	Return value	`return 0;` to `return 1;`	survived	killed
12	Return value	`return cost;` to `return 0;`	survived	killed

The weak suite killed 0 of 12. The strong suite killed 11 of 12. Here is the same story as a picture.

Identical 100% coverage, very different mutation results (12 hand-made mutants).

The mutant that nobody can kill

Did you spot mutant 1? It survived even the strong suite. Is that a gap in the tests?

No, and this is a lesson worth learning early. Changing > to >= on the weight check only matters at exactly 1,000 grams. At that weight the surcharge works out to (1000 - 1000) / 100 * 20, which is zero, so the output is identical either way. No test could ever tell the two versions apart. This is called an equivalent mutant, and every mutation tool produces some of them. They are noise you learn to recognize and dismiss.

Why this keeps happening in real projects

The weak suite was not written by a villain. Look at its assertions: not negative, not null. Both are true for almost every wrong answer too. A mutant that returns 0, 1, or a negated cost sails straight through.

A few habits make this easy to fall into:

Chasing a coverage percentage, so tests are written to execute lines rather than to pin down results.
Asserting on the shape of a result (it exists, it is positive) instead of its value.
Skipping boundary values, which is exactly where > versus >= bugs live.

Notice that all three are failures of assertions, not of effort. Coverage cannot see assertions at all, which is why it stays calm while the safety net has holes.

Using PIT without drowning in reports

Mutation testing has a reputation for being slow and noisy, and that reputation is partly earned. Each mutant means running tests again. As far as I know PIT reduces the cost by using coverage data to run only the tests that actually reach the mutated line, but I have not benchmarked that myself, so measure it on your own codebase.

A sensible way to start:

Run it on one package or one recent change first, not the whole project.
Read the survivors, not the score. Each surviving mutant points at a specific line and a specific missing assertion.
Dismiss equivalent mutants quickly and move on.
Do not chase 100% mutation score. Treat it as a smoke detector, not a target.

Notice how that last point mirrors the original problem. Any number becomes useless once people optimize the number instead of the behavior it was meant to represent.

Conclusion

Here is what the experiment showed. Two test suites, both green, both reporting 100% instruction, branch and line coverage on the same class. One of them killed none of twelve hand-made mutants, and the other killed eleven, with the twelfth being an equivalent mutant that no test could catch.

Coverage tells you where tests have been. Mutation testing tells you whether they would notice a problem. They answer different questions, and only the second one is about whether your safety net holds.

So the next time a report says 100%, ask a follow-up: if I broke this line on purpose, would anything fail? Then let a tool like PIT answer it for you. Remember, my mutation numbers came from a hand-built harness, so run PIT on your own code and trust its report over my table.

Tags

Learn secure SDLC practices and the rest of the CISSP domains for $19.99

Java Code Geeks — Tue, 20 Oct 2026 10:30:30 +0000

Meta JCG

Learn secure SDLC practices and the rest of the CISSP domains for $19.99

TL;DR: Study all eight CISSP domains with lifetime access to the CISSP Security & Risk Management Training Bundle for $19.99 (MSRP $424).

The CISSP exam spans eight domains, from risk management to secure software development, and preparing for all of them takes a lot of material. You can study each domain separately with The CISSP Security & Risk Management Training Bundle, and lifetime access is on sale for $19.99 (MSRP $424).

264 lectures across all eight CISSP domains

Across eight courses, you get 264 lectures and about 21 hours of content. Each course focuses on one domain, so you can start with the areas you know least instead of working through one long course from beginning to end.

Early courses teach security and risk management, asset classification, and security engineering, including how cryptography and system vulnerabilities affect architecture decisions. That knowledge applies directly when you review a system design or decide which risks a project can accept. Later courses move into network security, identity and access management, security testing, and daily security operations like logging, monitoring, and incident response.

For developers, the final course on security in the software development life cycle may be the most useful one day to day. You’ll learn how to plan each SDLC phase with risk in mind, choose the right SDLC model for a project, and run a risk analysis on your software’s security. Architects and team leads also get the managerial side, including the difference between role-based and rule-based access control and how to measure whether security controls are working.

Every course has a 5.0/5 average rating. You can watch on desktop or mobile, and a basic understanding of computers, networks, and security will help before you start.

Study for the CISSP exam one domain at a time, on your own schedule.

For a limited time, get the CISSP Security & Risk Management Training Bundle on sale for $19.99 (MSRP $424).

The CISSP Security & Risk Management Training Bundle

See Deal

StackSocial prices subject to change.

Tags

Java Code Geeks

MCP Logging in Spring AI

1. What Is MCP? What Is MCP Logging?

2. Code Example

2.1 Dependencies and Configuration

2.2 Server: Tool That Emits Log Notifications

2.3 Server: Registering the Tool

2.4 Client: Consuming Log Notifications

2.5 Output

3. Conclusion

Thank you!

A Guide to Structured Output in Spring AI

1. What Is Structured Output?

2. Code Example

2.1 Dependency and Configuration

2.2 Domain Entity

2.3 Custom Output Converter

2.4 Service — All Five Techniques in One Class

2.5 Controller

2.6 Main Class

2.7 Code Run and output

4. Conclusion

Thank you!

The Economics of Flaky Tests: What They Really Cost a Team

The Hidden Tax

What the Research Actually Says

Google’s Numbers

What Causes Them

Why Small Rates Add Up Fast

A Simple Cost Model

What to Do About It

What We Have Learned

Thank you!

[DEALS] Koofr Cloud Storage: Lifetime Subscription (1TB) (75% off) & Other Deals Up To 98% Off – Offers End Soon!

Thank you!

BEAM Supervision Trees and “Let It Crash”: What Java Services Can Steal from Erlang

Where “Let It Crash” Comes From

How a Supervision Tree Works

Workers and Supervisors

Restart Strategies

The Safety Valve

What Java Teams Can Borrow

A Tiny Supervisor You Can Run

Where the Analogy Breaks

What We Have Learned

Thank you!

Strings and Unicode: UTF-16, Compact Strings, and Why Emoji Break charAt

The Bug Behind a Single Smiley

What a Java String Really Stores

Chars Are 16-Bit Units

Three Different Answers to “How Long?”

A Short Program You Can Run

Compact Strings: Same API, Smaller Memory

One Character Can Double a String

Choosing the Right Tool

What We Have Learned

Thank you!

[FREE EBOOKS] No One Works Here, Rapid Reculturing & Four More Best Selling Titles

No One Works Here: How AI-Driven Enterprises Are Raising the Bar for Business, Leadership, and Competition ($30.00 Value) FREE for a Limited Time

Rapid Reculturing: Transforming Organizations at Pace and Scale ($30.00 Value) FREE for a Limited Time

Strategic Approaches to Intrusion Detection in Cloud-IoT Ecosystem ($225.00 Value) FREE for a Limited Time

The New Rules of AI Search: SEO for visibility in ChatGPT, Google Gemini and Generative Search ($26.99 Value) FREE for a Limited Time

10 Canva AI Features Every Creator Should Use in 2026 ($21 Value) FREE For a Limited Time

How to Build Your First Notion Dashboard in Minutes ($21 Value) FREE For a Limited Time

Thank you!

JFR Event Streaming: Continuous Production Profiling Without a Vendor Agent

Why You May Not Need an Agent

How Event Streaming Works

Inside the Same JVM

From Another Process

A Small Example You Can Run

What Does It Cost?

A Practical Production Setup

Streaming Versus Dump Files

What We Have Learned

Thank you!

Mutation testing with PIT: why 100% coverage proves almost nothing

The experiment: 100% coverage, zero mutants killed

The code under test

Two test suites