1. Overview

Jackson has been the most popular JSON processing library in the Java ecosystem for over a decade. After years of incremental updates in the 2.x line, the release of Jackson 3.0 introduces a major architectural overhaul designed to address long-standing technical debt and modernize its API.

In this tutorial, we’ll explore key changes in Jackson 3, how they impact our existing codebases, and the steps required to migrate from the 2.x line.

2. Technical Prerequisites and Migration Path

Let’s review the foundational changes in Jackson 3, including minimum requirements and the necessary steps to prepare our project for migration.

2.1. Java 17 Baseline

Jackson 3.0 raises its minimum supported JDK version from Java 8 to Java 17. This allows Jackson to natively use modern Java language features, such as Java Records or pattern matching.

Before migrating to Jackson 3.0, we should ensure that our project meets this requirement. If not, we must consider upgrading the Java version in our project or remaining on the Jackson 2.x line.

2.2. Artifacts and GroupId

The new major Jackson version introduces a completely new groupId for its artifacts – tools.jackson.core, replacing com.fasterxml.jackson.core. This change allows Jackson 2.x and 3.x to coexist on the classpath in parallel during gradual migrations.

To install the new version of the library, we add it to our pom.xml:

<dependency> 
    <groupId>tools.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>3.2.1</version>
</dependency>

Alternatively, if we want to add a dedicated mapper for another format, such as XML, we need to include its specific module:

<dependency>
    <groupId>tools.jackson.dataformat</groupId>
    <artifactId>jackson-dataformat-xml</artifactId>
    <version>3.2.1</version>
</dependency>

For these format-specific modules, the group is tools.jackson.dataformat. It’s also worth noting that the jackson-annotations dependency still remains under the old com.fasterxml.jackson.core group. This exception ensures that our core domain models with Jackson annotations do not require modifications when upgrading.

2.3. Package Name Changes

Because of the artifacts groupId change, the base Java package has also shifted from com.fasterxml.jackson to tools.jackson. When migrating projects, we need to update our import statements:

// Remove Old Jackson 2.x imports
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.JsonNode;
// Use New Jackson 3.x imports
import tools.jackson.databind.ObjectMapper;
import tools.jackson.databind.json.JsonMapper;
import tools.jackson.databind.JsonNode;

2.4. Android Compatibility

Because Jackson 3 relies entirely on Java 17, Android projects must be properly configured to support these language features.

Android developers should to target API level 34 (Android 14) or enable core library desugaring in their build configuration to use Jackson 3.

2.5. Removal of Deprecated Methods

As part of the major version bump, Jackson 3 removes all classes, methods, and configurations that had the @Deprecated annotation in the 2.x line. If our current codebase uses any legacy methods, we must replace them with 3.x alternatives before the migration.

Now, let’s move on to specific functional changes in Jackson 3.

3. Immutable ObjectMapper and the Builder Pattern

In previous versions, ObjectMapper instances were mutable. By modifying configurations or registered modules on an active mapper after initialization, we risked running into thread-safety issues, such as race conditions when concurrent threads tried to read and alter the mapper’s state simultaneously.

Jackson 3 solves this by enforcing strict immutability for its mappers. It removes direct configuration methods on ObjectMapper. Instead, we use the builder pattern and format-specific builders to configure our mappers before instantiation.

3.1. Building a JsonMapper

Let’s see how to construct and configure a JsonMapper using the available API:

JsonMapper mapper = JsonMapper.builder()
  .enable(SerializationFeature.INDENT_OUTPUT)
  .disable(JsonWriteFeature.ESCAPE_NON_ASCII)
  .configure(DateTimeFeature.WRITE_DATES_AS_TIMESTAMPS, false)
  .build();

Here, we initialize a builder for the JSON format. We enable pretty-printing, disable the escaping of non-ASCII characters, and tell Jackson not to serialize dates as numeric timestamps.

Jackson uses Java enums as sets of feature toggles to control parsing, serialization, and mapping behavior. We can find general configuration options in the SerializationFeature, DeserializationFeature, and MapperFeature enums. For format- or type-specific requirements, Jackson provides dedicated enums such as JsonWriteFeature (for JSON generation) and DateTimeFeature (for date handling).

3.2. Copying Mappers

If we need a slightly modified version of an existing mapper, we can use the rebuild() method:

JsonMapper prettyMapper = mapper.rebuild()
  .enable(SerializationFeature.INDENT_OUTPUT)
  .build();

Note that prettyMapper and mapper from the previous snippet are completely different objects. The rebuild() method copies the internal configuration of the original mapper into a new builder, allowing us to spawn a new instance with slight modifications. Because the mappers are immutable, this operation is entirely thread-safe and won’t affect the original mapper.

3.3. Support for Alternative Data Formats

If our project requires a different data format, we simply switch to the corresponding format-specific builder. For example, we can configure an XmlMapper for XML or a YAMLMapper for YAML using their respective builders:

XmlMapper xmlMapper = XmlMapper.builder()
  .enable(SerializationFeature.INDENT_OUTPUT)
  .build();
YAMLMapper yamlMapper = YAMLMapper.builder()
  .disable(YAMLGenerator.Feature.WRITE_DOC_START_MARKER)
  .build();

4. Unchecked Exceptions

One of the biggest readability issues in Jackson 2.x was dealing with the checked JsonProcessingException and IOException during serialization and deserialization. Supporting them inside Java Streams or lambda expressions often led to verbose try-catch blocks or custom wrapper utilities.

In Jackson 3, JacksonException replaces JsonProcessingException as the root exception, and it now extends RuntimeException:

List<User> users = jsonPayloads.stream()
  .map(json -> mapper.readValue(json, User.class)) // No try-catch needed!
  .toList();

This change significantly cleans up our stream operations. Because the exception is unchecked, the compiler no longer forces us to handle it immediately. We can omit the clutter of try-catch blocks within our lambdas, resulting in much cleaner code.

5. Built-in Java 8+ Features

Historically, to properly handle Java 8 features like java.time classes, java.util.Optional, or constructor parameter name detection, we had to explicitly include and register three separate modules: jackson-datatype-jsr310, jackson-datatype-jdk8, and jackson-module-parameter-names.

Since Jackson 3 targets Java 17, these three modules are now integrated into jackson-databind. We can serialize and deserialize LocalDateTime and Optional properties immediately upon creating a new mapper:

public record Event(String title, Optional<String> description, LocalDateTime eventDate) {}
// ...
Event event = new Event("Tech Talk", Optional.of("Jackson 3 overview"), LocalDateTime.now());
JsonMapper mapper = JsonMapper.builder().build();    
String json = mapper.writeValueAsString(event);
Event deserialized = mapper.readValue(json, Event.class);

This native support significantly simplifies the codebase when working with Java 8+ types, as it requires no additional configuration.

6. Configuration Defaults and Behavioral Changes

Jackson 3 changes several default settings to reflect modern development practices and community feedback. A full list of changes can be found in the official documentation. We describe the most impactful ones.

6.1. FAIL_ON_UNKNOWN_PROPERTIES Defaults to false

In Jackson 2.x, encountering unknown JSON fields during deserialization threw an UnrecognizedPropertyException by default unless we explicitly disabled it on the mapper.

In Jackson 3.0, DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES defaults to false. Jackson safely ignores unrecognized fields in incoming JSON payloads unless we explicitly set this flag to true. Let’s verify this:

record User(String name) {}
// ...
JsonMapper mapper = JsonMapper.builder().build();
// The JSON contains "unknownField" which is not present in the User class
String json = "{\"name\":\"Alice\", \"unknownField\":\"ignored_value\"}";
    
// This executes without throwing an exception
User user = mapper.readValue(json, User.class);

In some cases such as strict API validations, it may be necessary to throw an exception when encountering an unknown field. To achieve this, we reenable the feature on the builder:

JsonMapper strictMapper = JsonMapper.builder()
    .enable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
    .build();
User strictUser = strictMapper.readValue(json, User.class);

This now throws an UnrecognizedPropertyException.

6.2. Fast Floating-Point Operations

Jackson 3 enables fast floating-point parsing and writing algorithms by default, significantly increasing performance when processing heavy numerical payloads.

In the late Jackson 2.x releases, we had to manually activate this behavior by configuring the factory features StreamReadFeature.USE_FAST_DOUBLE_PARSER:

JsonFactory.builder()
    .enable(StreamReadFeature.USE_FAST_DOUBLE_PARSER)
    .build()

In Jackson 3, we benefit from this performance boost right out of the box.

6.3. Simplified Date and Time Formatting

Jackson 3 introduces DateTimeFeature, consolidating date and time configuration options across standard JDK dates, Java 8 java.time, and Joda-Time into a single, unified feature set:

JsonMapper mapper = JsonMapper.builder()
    .enable(DateTimeFeature.WRITE_DATES_AS_TIMESTAMPS)
    .build();

We can now format dates globally across all date types.

6.4. Standard Bean Naming

Jackson 3 bakes standard bean naming into its core engine as the permanent default behavior. Because this behavior is no longer optional, Jackson 3 removed the MapperFeature.USE_STD_BEAN_NAMING configuration flag entirely.

Now, we get more consistent property naming out of the box, as we can derive property names from standard getters and setters. Consider a Java class with a getter getTheURL():

class Link {
    private String address;
    public Link(String address) {
        this.address = address;
    }
    public String getTheURL() {
        return address;
    }
}
// ...
String json = mapper.writeValueAsString(new Link("https://baeldung.com"));

Note that Jackson derives JSON property names from getters instead of private fields. In this example, the getter getTheURL() determines the output key theURL:

{"theURL":"https://baeldung.com"}

The backing private field address isn’t considered.

7. Enhancements to the JsonNode Tree Model

The JsonNode tree model remains crucial for working with unstructured data. In Jackson 3, the API underwent several structural updates to make traversing JSON trees safer and more intuitive.

First, the node trees now expose dedicated subtypes, such as ObjectTreeNode and ArrayTreeNode. This shift provides better type-safety and clearer intentions when manipulating complex JSON structures, compared to checking node types on a generic JsonNode interface.

The API also introduces safer method names to align with Java conventions. For example, JsonParser.getText() has been renamed to getString() to avoid ambiguity and standardize the naming scheme.

Finally, Jackson 3 introduces optional value accessors, such as intValueOpt(), asInt(), and required(). They eliminate the need for manual null checking and provide a much cleaner approach to extracting data.

Here’s an example showing all the three updates:

String json = "{\"product\":\"Laptop\",\"price\":1200}";
JsonNode root = mapper.readTree(json);
String product = root.get("product").asString();
OptionalInt price = root.get("price").intValueOpt();

In this snippet, we parse a raw JSON string into a tree model. We then safely navigate the structure using the get() method and extract typed values using the new asString() and intValueOpt() accessors. This approach bypasses the clunky type-checking and manual casting that were often required in previous versions.

8. Conclusion

In this article, we explored the major architectural and functional changes introduced in Jackson 3.0. By raising the baseline to Java 17, the library drops years of technical debt and natively embraces modern Java features like Records, java.util.Optional, and the java.time API without the need for external modules.

The shift toward strict immutability via the builder pattern successfully resolves historic thread-safety issues, while the transition to unchecked exceptions greatly improves developer readability, especially when working with modern Java Streams. Additionally, smarter configuration defaults and Tree Model enhancements make everyday JSON processing cleaner and more intuitive.

While migrating from the 2.x line requires some work, the long-term benefits of a faster, safer, and more robust API make the upgrade well worth the effort.

As always, the complete source code for all the examples is available over on GitHub.

The post What’s New in Jackson 3? first appeared on Baeldung.

       

1. Overview

Modern applications demand faster, more reliable, and more secure network communication, and HTTP/3 addresses these requirements.

Java introduced the modern HttpClient API in Java 11 to replace the legacy HttpURLConnection API and provide built-in support for HTTP/2, asynchronous communication, and WebSocket integration. With Java 26, the HttpClient API continues its evolution by adding support for HTTP/3.

In this tutorial, we’ll explore how Java 26 extends the HttpClient API with HTTP/3 support and use it to build a Java application.

2. What Is HTTP/3?

As the name suggests, HTTP version 3, or simply HTTP/3, is the newer version of the Hypertext Transfer Protocol.

HTTP/3 delivers significant improvements in performance, reliability, and security by replacing TCP with Quick UDP Internet Connections (QUIC) as its transport layer. QUIC combines the transport and TLS 1.3 handshake into a single round trip, which cuts connection setup time compared to TCP. It’s particularly effective on high-latency and mobile networks.

QUIC streams are independent, so a lost packet affects only that stream, whereas other streams continue without interruption. Most modern browsers now support HTTP/3 and use it automatically when a server advertises it.

3. Using HTTP/3 in Java 26

We can continue using the same high-level HTTP Client API while the runtime handles protocol negotiation internally.

3.1. Declaring HTTP/3

Before we send an HTTP request, we first create an instance of an HttpClient. HttpClient instances can be configured and created via their builder:

public Http3Demo() {
    this.client = HttpClient.newBuilder()
      .version(HttpClient.Version.HTTP_3)
      .build();
}

When we call .version(HttpClient.Version.HTTP_3), we instruct the client to prefer HTTP/3 for outgoing requests. By default, Java 26 uses HTTP/2, so existing applications require no change if we don’t need HTTP/3.

3.2. Protocol Discovery

If we set the client to use HTTP/3, the client needs to discover whether the server supports it. As HTTP/3 runs over QUIC, a UDP-based transport, whereas HTTP/1.1 and HTTP/2 run over TCP, the client can’t upgrade an existing connection to HTTP/3 the way it switches between the older versions.

We choose how the client discovers HTTP/3 per request by setting HttpOption.H3_DISCOVERY. Three modes are supported:

• ANY (default): The client uses its own algorithm to establish a connection. It may attempt HTTP/3 over QUIC and HTTP over TLS/TCP, using whichever succeeds first.
• HTTP_3_URI_ONLY: The client attempts HTTP/3 directly at the host and port from the request URI without using Alternative Services. This succeeds only if the server is already listening for HTTP/3 on that port.
• ALT_SVC: The client relies only on HTTP Alternative Services to discover HTTP/3. Servers advertise HTTP/3 through HTTP Alternative Services, defined in RFC 7838. A server can answer the first request over HTTP/1.1 or HTTP/2 and include an Alt-Svc header frame that names an h3 endpoint. The header tells the client that the same resource is available at a given host and port over HTTP/3. Then, the client can send later requests over HTTP/3. Alternatively, the server can also advertise HTTP/3 via an HTTP/2 ALTSVC frame.

If we don’t set H3_DISCOVERY, the client uses ANY by default. This option only works when HTTP/3 is the preferred version (set on the client or the request).

3.3. Sending Requests

Let’s see this in action. Our fetch() method builds and sends an HttpRequest:

public HttpResponse<String> fetch(String url) throws IOException, InterruptedException {
    HttpRequest request = HttpRequest.newBuilder(URI.create(url))
      .GET()
      .setOption(HttpOption.H3_DISCOVERY, HttpOption.Http3DiscoveryMode.HTTP_3_URI_ONLY)
      .build();
    return this.client.send(request, BodyHandlers.ofString());
}

Here, we set the discovery mode using setOption(). We use HTTP_3_URI_ONLY to attempt HTTP/3 directly at the server’s host and port, without waiting for the server to advertise it via Alt-Svc.

Note that HttpOption.H3_DISCOVERY takes effect in our example because we set HTTP/3 as the client’s preferred version. If neither the client nor the request preferred HTTP/3, the client would ignore H3_DISCOVERY.

BodyHandlers.ofString() instructs the client to read the response body as a string. The client decodes the response using the charset specified in the Content-Type header, falling back to UTF-8 if no valid charset is provided.

We continue to handle the same checked exceptions we handled with HttpClient: IOException for network or protocol failures, and InterruptedException (because the send() method blocks the calling thread).

4. Protocol Selection and Error Handling

Setting HTTP/3 preference doesn’t guarantee the client will use it. Let’s discuss how the client picks a protocol version and how it informs us it can’t use HTTP/3.

4.1. How the Client Chooses the Protocol Version

As with HTTP/2, several factors decide the actual protocol version for each request.

HTTP/3 stays off by default. We turn it on by setting the preferred version to HTTP/3 when building the client or an individual request. Once HTTP/3 is enabled, the discovery mode guides how the client establishes the exchange. If we don’t set the mode, the client uses the default mode.

However, there are exceptions that can override our preference:

• The client never sends a request over HTTP/3 unless the URI uses the https scheme.
• It also skips HTTP/3 when a proxy is used.

4.2. Handling UnsupportedProtocolVersionException

Sometimes, a client doesn’t support HTTP/3. Such a client may throw an UnsupportedProtocolVersionException:

• when building the client with HTTP/3 as its preferred version
• when sending a request that enables HTTP/3 but has the discovery mode set to HTTP_3_URI_ONLY

Since our example uses HTTP_3_URI_ONLY, production code should account for this exception around the send() call, alongside the IOException and InterruptedException we already handle.

5. Verifying HTTP/3 Support With Unit Tests

Let’s verify that our HTTP/3 client handles both supported and unsupported scenarios.

5.1. Verifying a Valid HTTP/3 Endpoint

Let’s send a request to https://cloudflare-quic.com/, a public endpoint that Cloudflare provides for HTTP/3 experiments:

@Test
void givenValidHttpsUrl_whenFetch_thenReturnsResponseBody() {
    HttpResponse<String> response;
    try {
        response = new Http3Demo().fetch(HTTP3_URL);
    } catch (IOException | InterruptedException e) {
        Assumptions.abort("Skipping: cloudflare-quic.com unreachable in this environment - " + e.getMessage());
        return;
    }
    assertEquals(200, response.statusCode());
    assertEquals(HttpClient.Version.HTTP_3, response.version());
}

We call the endpoint with Http3Demo.fetch() and expect a successful 200 OK response. Then, we use response.version() to verify whether the client successfully negotiated HTTP/3.

5.2. Rejecting a Plain HTTP Endpoint

In this test, we start a local server using plain HTTP and attempt to fetch it through our HTTP/3 client. We expect the request to throw an UnsupportedProtocolVersionException:

@Test
void givenPlainHttpUrl_whenFetch_thenThrowsUnsupportedProtocolVersionException() {
    assertThrows(UnsupportedProtocolVersionException.class,() -> new Http3Demo().fetch(
      plainBaseUrl + "/hello"));
}

This happens because HTTP/3 requires a secure HTTPS connection and uses QUIC as its transport protocol, while our local server only supports HTTP.

6. Conclusion

In this article, we learned about HTTP/3 support in Java 26’s HttpClient, which we enable by setting the version to HTTP/3 on the builder.

The rest of the HttpClient API stays the same. HTTP/2 remains the default, so our existing code continues to work without modifications. When the server doesn’t support HTTP/3, the client can use HTTP/2 or HTTP/1.1 instead in some cases.

The API also supports multiple discovery modes for more control over protocol selection.

As always, the code used in this article is available over on GitHub.

The post HTTP/3 Support in HTTP Client API in Java 26 first appeared on Baeldung.

       

1. Overview

MCP (Model Context Protocol) is an open-source, JSON-RPC-based (JavaScript Object Notation-Remote Procedure Call) protocol. It provides a standardized way for AI (Artificial Intelligence) applications to connect to external tools, services, and data sources. Therefore, it eliminates the need for custom integrations.

Logging in MCP gives servers a standardized way to send structured, severity-tagged log messages to clients. This might be especially useful while debugging an MCP server.

In this tutorial, we’ll discuss MCP logging in Spring AI. Firstly, we’ll give brief information about MCP logging. Then, we’ll discuss logging both in an MCP server and client.

2. Basic Information About MCP Logging

An MCP server pushes log messages to an MCP client as notifications/message JSON-RPC notifications. This one-way notification message from the server to the client contains a severity level, an optional logger name, and the log message.

The MCP client can send the logging/setLevel JSON-RPC request to the server to configure log-message verbosity. Consequently, the server only sends log messages that meet or exceed the requested severity level. The client can dynamically adjust log verbosity by issuing another logging/setLevel.

An important caveat is that the July 2026 spec revision (2026-07-28) formally deprecated the logging feature along with other features, in favor of newer mechanisms. However, existing implementations will continue to work for at least a year. It’s recommended that newer implementations migrate to using stderr (standard error) for the stdio (standard input/output) transport and OpenTelemetry for structured observability.

3. Maven Dependencies

Let’s start by adding the necessary Maven dependencies to our pom.xml:

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

The MCP client starter dependency enables a Spring AI application to connect to MCP servers and use their tools. On the other hand, we use the MCP server starter dependency to turn a Spring Boot application into an MCP server. The dependency lets the application expose tools and resources to other LLM (Large Language Model) applications.

We use the Spring AI BOM (Bill of Materials) to avoid the risk of version conflicts between Spring AI dependencies:

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

Therefore, we don’t have to specify the versions of MCP starters explicitly.

4. Logging on the Server Side

Let’s start by discussing logging in the MCP server. The server we’ll discuss exposes a tool that an MCP client can run whenever a user requests a password strength evaluation.

4.1. Tool Implementation

The PasswordStrengthService class holds the actual tool implementation, the checkStrength() method exposed by the @McpTool server annotation. It’s a Spring bean since it’s annotated with @Service:

@Service
public class PasswordStrengthService {
    ...
    @McpTool(name = "check_password_strength", 
      description = "Evaluates password strength and returns a score with recommendations.")
    public PasswordStrengthResult checkStrength(
        @McpToolParam(description = "The password to evaluate", required = true) String password,
	  McpSyncRequestContext ctx) {
        ...
    }
}

The checkStrength() method, i.e., the tool, takes two parameters. The first one is the password to be evaluated. The tool checks whether the password is at least 12 characters long, contains at least one uppercase letter, and contains at least one digit. It also checks whether the password matches common passwords such as “123456” or “qwerty”.

The second parameter is of type McpSyncRequestContext, which we’ll use for logging. The Spring AI MCP annotations framework injects it automatically. An MCP server uses an object of this special type to log messages. It doesn’t write the log messages directly to the stdout (standard output) stream. Instead, it packages them into standard MCP protocol notification payloads and sends them over the transport layer, like stdio or SSE (Server-Sent Events), to the client. We use the stdio transport in our example.

The McpSyncRequestContext interface provides several logging methods such as debug(), info(), warn(), and error(). For example, if the password matches a common password, we log it using the ctx.error(“Password found in common-password list”) call in our example:

if (COMMON_PASSWORDS.contains(password.toLowerCase())) {
    ctx.error("Password found in common-password list");
    issues.add("commonly used");
}

Therefore, on the server side, we can choose the logging level per call.

4.2. MCP Server

The McpLoggingServerApplication class provides the Spring Boot entry point for the MCP server process:

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

When the server process starts, Spring AI’s MCP server auto-configuration scans for methods annotated with @McpTool. Then, it registers and exposes the detected tools over the stdio transport. A connected client can therefore discover and call them.

We need to enable the stdio transport in the server’s configuration file, application-server.properties:

spring.ai.mcp.server.stdio=true

Besides, we must prevent the server application from printing logs to stdout. The stdout stream is dedicated to exchanging the MCP protocol’s JSON-RPC messages:

spring.main.web-application-type=none
spring.main.banner-mode=off
logging.pattern.console=

Setting spring.main.web-application-type to none prevents Spring Boot from starting a web server. This means that no web-related startup logs are emitted. Setting spring.main.banner-mode to off suppresses the Spring Boot banner that is normally printed to stdout on startup. Finally, logging.pattern.console= strips the pattern formatting in logs.

5. Handling Logs on the Client Side

Let’s now discuss logging in the MCP client.

5.1. MCP Client

Similar to McpLoggingServerApplication, the McpLoggingClientApplication class provides the Spring Boot entry point for the MCP client process:

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

On startup, the client boot starter reads the spring.ai.mcp.client.stdio.connections.* properties in the application-client.properties file and launches the server as a child process. For example, the configuration property spring.ai.mcp.client.stdio.connections.password-strength-logging-server.args specifies which arguments the client passes to the server when spawning it. The stdio segment in these configuration properties selects the stdio transport for the named connection, password-strength-logging-server.

The spring.ai.mcp.client.type=SYNC configuration property selects the synchronous client implementation, i.e., McpSyncClient. Therefore, client calls block until the server responds.

5.2. Logging Handler

To capture the notification logs sent by the server on the client side, we have to use the @McpLogging client annotation:

@Component public class PasswordStrengthMcpClientHandlers {
    ...
    @McpLogging(clients = "password-strength-logging-server")
    public void handleLoggingMessage(McpSchema.LoggingMessageNotification notification) {
        LOGGER.info("Received server logging notification [{}]: {}"
          , notification.level(), notification.data());
        receivedLogs.add(notification);
    }
    ...
} 

@McpLogging is a Spring AI MCP annotation that registers a method as a notification handler for a specific MCP client connection. The handler’s name is handleLoggingMessage() in our example. The connection’s name is password-strength-logging-server, which matches the ID configured for the stdio connection in the server’s configuration file, application-server.properties:

spring.ai.mcp.server.name= password-strength-logging-server

The handler’s parameter, notification, is the deserialized payload of an MCP logging notification. Its level() method prints the log severity (e.g., DEBUG, ERROR). Its data() method, on the other hand, contains the actual log sent by the server.

We’ve already seen that the server can choose the logging level per call since the McpSyncRequestContext interface provides several logging methods such as warn() and error(). However, the client can set the server’s logging level. Therefore, the server can filter out notification messages at a specific level and below:

mcpSyncClient.setLoggingLevel(McpSchema.LoggingLevel.WARNING);

Here, this client-side call instructs the server to filter out anything below WARNING. For example, the server doesn’t send notifications with DEBUG or INFO levels.

6. An Example

When we send “weak“ as the password to be evaluated by the MCP server, the logging handler prints the following list of log messages:

Received server logging notification [WARNING]: Password shorter than recommended 12 characters
Received server logging notification [WARNING]: Password missing uppercase letters
Received server logging notification [WARNING]: Password missing digits
Received server logging notification [INFO]: Final score: 25

This is expected since the password “weak“ is shorter than 12 characters and doesn’t contain uppercase letters and digits. It only satisfies the common password criterion. Therefore, it gets a final score of 25 out of 100.

Our example consists of only an MCP server and client. But if the client were an LLM-orchestrated agent, a list of transactions similar to the following list would have occurred:

• User -> Client: The user asks the following question: “How strong is the password weak?”
• Client -> LLM: The client sends the user’s message to the LLM together with the tool information received from the MCP server at session start
• LLM -> Client: The LLM doesn’t call the server itself. Instead, it returns a response that indicates that it wants to call the tool checkStrength with password=weak
• Client -> Server: The client issues the actual JSON-RPC request over the stdio transport
• Server -> Client: The server returns the response we saw earlier as a JSON-RPC response
• Client -> LLM: The client forwards the tool result back to the conversation and asks the LLM to continue
• LLM –> User: The LLM generates a natural-language answer synthesizing the structured result from the tool, something like: “That password is very weak. It’s only 4 characters long — you’ll need at least 12 — and it doesn’t include any uppercase letters or digits. I can make suggestions if you like.“

7. Conclusion

In this article, we discussed MCP logging in Spring AI. Firstly, we learned about how logging works within the MCP ecosystem. Then, we examined the details of MCP logging on an MCP server evaluating a password’s strength. We saw that we can use the logging methods in the McpSyncRequestContext interface to print log messages at different severity levels.

Then, we discussed logging on the MCP client. We learned that we can use a handler annotated with @McpLogging for handling logs. Finally, we saw an example using the server and client and discussed the interaction between an LLM, the client, and the server when a user asks for an evaluation of a password’s strength.

As usual, the complete source code for the examples is available over on GitHub.

The post MCP Logging in Spring AI first appeared on Baeldung.

       

Comments

• In reply to Hayrullah. Hey, Hayrullah. Thanks for the ... by Ulisses Lima
• Thank you for sharing 🙂 by Hayrullah

 

1. Spring and Java

>> Project Loom in IntelliJ IDEA: Virtual Threads, Scoped Values, and Structured Concurrency [jetbrains.com]

A hands-on tour of the three Loom pillars: virtual threads, scoped values, and structured concurrency. This show you exactly what each feature buys and the tooling coming along with it. Solid stuff.

Also worth reading:

• >> Post-Quantum Cryptography in Spring Boot: Four Patterns You Can Ship This Sprint [infoq.com]
• >> The Grails Plugin Has a New Home: Apache Grails [jetbrains.com]
• >> Module Imports [javaspecialists.eu]

Webinars and presentations:

• >> Episode 68 “Operator Overloading with Type Classes” [AtA] [inside.java]
• >> A Bootiful Podcast: Joe Grandja on Spring Authorization Server, OAuth, and so much more [spring.io]
• >> Spring Office Hours Podcast: S5E21 – Pro Spring Boot 4 with Felipe Gutierrez [spring.io]

Time to upgrade:

• >> IntelliJ IDEA 2026.2.2 Is Out! [jetbrains.com]
• >> Compose Multiplatform 1.12.0 Released [jetbrains.com]
• >> Quarkus Flow 1.0.0 released [quarkus.io]
• >> Quarkus 3.39 – Post-quantum cryptography support in TLS registry [quarkus.io]
• >> WildFly 41.0.1 is released! [wildfly.org]
• >> JHipster v9.3.0 [github.com/jhipster]
• >> Vert.x 4.5.33 and 5.1.7 [github.com/eclipse-vertx]
• >> Elasticsearch 9.4.6 and 8.19.21 [github.com/elastic]
• >> Zuul v4.1.5 [github.com/Netflix]
• >> Micronaut Core 5.1.13 [github.com/micronaut-projects]
• >> Helidon 4.5.4 [github.com/helidon-io]

2. Technical & Musings

>> Maybe We Shouldn’t Be Reviewing All This Code [martinfowler.com]

PR sizes really are ballooning, but the fix isn’t automating review away, it’s noticing that we’d been leaning on review to carry things that belongs much earlier in the flow. An interesting weekend read.

Also worth reading:

• >> AI-assisted genealogy [frankel.ch]
• >> DuckDB and the changing physics of analytics [allthingsdistributed.com]
• >> Making Your Data Ready for Agentic AI [martinfowler.com]
• >> An Accidental Blackboard [martinfowler.com]
• >> MAPS: Netflix’s Multimodal Asset Personalization at Scale [netflixtechblog.com]
• >> Running Apache Spark experiments in my sleep (and on a plane) [netflixtechblog.com]
• >> You Can’t “Vibe Code” Love [codinghorror.com]

3. Pick of the Week

And from last week, the free, fully virtual conference for our ecosystem:

>> IntelliJ IDEA Conf 2026 [jetbrains.com]

The post Java Weekly, Issue 662 first appeared on Baeldung.

       

1. Overview

LLM streaming delivers output token by token as it’s generated. This reduces latency, as users see the first results in the UI within milliseconds instead of waiting seconds for a complete answer.

For agents with structured output and reasoning-aware agents, streaming should enable incremental processing:

• parsing responses into Java objects as they arrive, and
• processing thinking blocks as they arrive as well

However, current major frameworks don’t support these functionalities.

In this tutorial, we’ll:

• briefly review the limitations of these frameworks
• and show how to use the Embabel Agentic AI Framework to process objects and thinking blocks incrementally, as they arrive in a stream

We’ll cover four cases:

• one object without reasoning
• multiple objects without reasoning
• multiple objects with reasoning but without tool calls
• multiple objects with both reasoning and tool calls

2. Structured Streaming: Framework Limitations

The major Java frameworks for LLM integration, Spring AI and LangChain4j, support streaming at a limited level. We can get a live stream of text as the model generates it, but neither framework turns that stream into a collection of typed objects out of the box.

The Spring AI’s entity() method, which converts model output into a Java object, works with the blocking call() method but not with stream(). The ChatClient API reference spells this out directly: “In the future, we will offer a convenience method that will let you return a Java entity with the reactive stream() method. In the meantime, you should use the Structured Output Converter.” 

LangChain4j has the same limitation. Its AiServices allows returning custom POJOs, lists, and enums only for non-streaming calls. For streaming, the return type must be a TokenStream, which gives us raw text as it arrives, plus rich callback hooks, but doesn’t provide typed objects as stream output.

In practice, anyone who wants a stream of structured objects with reasoning has to build that functionality themselves, as in this Baeldung’s article. This means choosing an NL-delimited format like JSONL, buffering tokens until a full line is available, parsing each line as JSON, and filtering out any thinking blocks along the way. Implementing this takes time away from the actual project.

This is where Embabel Agentic AI comes in handy. It natively provides the desired functionality, which we further explore.

3. Setup

First, let’s define the necessary Embabel dependencies:

<dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter-anthropic</artifactId>
    <version>${embabel-agent.version}</version>
</dependency>
<dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-test-internal</artifactId>
    <version>${embabel-agent.version}</version>
    <scope>test</scope>
</dependency>

The embabel-agent-starter-anthropic dependency provides the core classes we need to use Anthropic models with Embabel. In the examples in this tutorial, we use the Anthropic model claude-sonnet-4-5.

Additionally, we include embabel-agent-test-internal to use the AgentTestApplication test support class with @SpringBootTest.

3.1. Provider Support in Embabel

Note that model providers differ in how they combine streaming with thinking and tools. Anthropic’s native thinking produces explicit reasoning blocks, but other providers may not surface reasoning in the same way.

Embabel supports over a dozen LLM providers, with examples using OpenAI published on Baeldung in the past.

3.2. ParkingRecommendation

We’ll stream ParkingRecommendation objects in all tests throughout the article:

The record includes four scalar properties: parking scenario (scenario), chosen option cost (estimatedTotalCost), summary, and chosen option (enumeration Option).

4. Streaming a Single Object

void whenStreaming_thenReceivesParkingRecommendation() {
     streamParkingRecommendations(PARKING_PROMPT);
  }

Flux<ParkingRecommendation> stream = new StreamingPromptRunnerBuilder(runner)
  .streaming()
  .withPrompt(PARKING_PROMPT)
  .createObjectStream(ParkingRecommendation.class);
stream
  .timeout(Duration.ofSeconds(120))
  .doOnNext(rec -> {
    received.add(rec);
    logger.info(
      "Received parking recommendation: scenario={}, option={}, cost={}, summary={}",
      rec.scenario(),
      rec.chosenOption(),
      rec.estimatedTotalCost(),
      rec.summary());
    }).blockLast(Duration.ofSeconds(240));

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreaming_thenReceivesParkingRecommendation

17:34:13.781 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Midtown Manhattan parking for 3-hour client meeting with 30-minute arrival buffer, option=GARAGE, cost=90, summary=Choose garage parking. The meeting duration (3 hours) exceeds the metered parking limit (2 hours), eliminating that option. Street parking in Midtown Manhattan is extremely unreliable and searching could make you late for the meeting. The guaranteed spot and ability to stay for the full meeting duration justifies the $90 cost for this professional context.

void whenStreamingMultipleScenarios_thenReceivesRecommendationPerScenario() {
    streamParkingRecommendations(TIMED_PARKING_PROMPT);
}

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreamingMultipleScenarios_thenReceivesRecommendationPerScenario

18:31:24.200 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Early morning (before 8am), option=STREET, cost=0, summary=Arrive before 8am to take advantage of free street parking. Meters are not enforced until 8am, providing zero-cost parking. Be prepared to feed the meter or move to a garage if your meeting extends past 8am.
18:31:27.354 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Business hours (9am-5pm), option=GARAGE, cost=45, summary=For a 3-hour business meeting with only a 30-minute arrival window, a parking garage is the most reliable option. Street parking in Midtown is extremely competitive during peak hours, and the time spent searching could cause you to miss your meeting. Garage rates typically range $35-55 for 3 hours in Midtown Manhattan.
18:31:28.889 [HttpClient-4-Worker-0] WARN  StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
18:31:28.895 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Evening (after 6pm), option=STREET, cost=0, summary=Street meters become free after 6pm, making this the best option if you're confident your 3-hour meeting will end before 9pm. However, have a backup plan: identify a 24-hour garage nearby in case your meeting runs late, as many garages close at 9pm and you could be locked in or locked out.

void whenStreamingWithThinking_thenReceivesReasoningAndRecommendation() {
    LlmOptions thinkingOptions = new LlmOptions().withThinking(Thinking.withTokenBudget(8000));
    PromptRunner runner = ai.withDefaultLlm().withLlm(thinkingOptions);
    streamParkingRecommendationsWithThinking(runner, TIMED_PARKING_PROMPT);
}

Flux<StreamingEvent<ParkingRecommendation>> stream = new StreamingPromptRunnerBuilder(runner)
  .streaming()
  .withPrompt(prompt)
  .createObjectStreamWithThinking(ParkingRecommendation.class);

.doOnNext(event -> {
  if (event.isObject()) {
      ParkingRecommendation rec = event.getObject();
      if (rec != null) {
          received.add(rec);
          logger.info("Received recommendation: scenario={}, option={}, cost={}, summary={}",
            rec.scenario(), rec.chosenOption(), rec.estimatedTotalCost(), rec.summary());
      }
  } else if (event.isThinking()) {
      reasoning.add(event.getThinking());
      logger.info("Received reasoning: {}", event.getThinking());
  }
})

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreamingWithThinking_thenReceivesReasoningAndRecommendation

21:34:05.311 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: The user is asking for parking recommendations for Midtown Manhattan across three different time scenarios. I need to analyze each scenario and provide recommendations in JSONL format.
21:34:05.311 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Let me think through each scenario:
...
21:34:13.300 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Early morning (before 8am), option=STREET, cost=0, summary=Street parking is free before 8am in Midtown. Arrive early to secure a spot while meters are not enforced. No cost advantage to using garage or paid meter.
21:34:14.003 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: For business hours, considering reliability vs cost. 30-minute window suggests tight schedule, and 3-hour stay during peak hours means garage offers certainty despite higher cost
21:34:16.867 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Business hours (9am-5pm, 3-hour stay), option=GARAGE, cost=35, summary=During peak business hours with only a 30-minute arrival window, garage parking ($30-40 for 3 hours) provides guaranteed availability and eliminates time spent searching. Street meters ($12-15 for 3 hours) are cheaper but finding spots in Midtown during business hours is challenging and risky given the tight timeline.
21:34:18.275 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: Evening scenario has free street parking but garage closure risk. If arriving at 6pm with 3-hour stay, would exit at 9pm exactly when garages close - cutting it too close. Street parking is free and has no closure risk
21:34:19.337 [HttpClient-4-Worker-0] WARN StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
21:34:19.359 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Evening (after 6pm, 3-hour stay), option=STREET, cost=0, summary=Street meters are free after 6pm, making this the clear choice. Additionally, with garages closing at 9pm and a 3-hour stay, there's significant risk of garage closure before departure. Street parking eliminates both cost and time constraints.

void whenStreamingWithThinkingAndTooling_thenReceivesRecommendationAndReasoning() {
    PromptRunner runner = ai.withDefaultLlm()
      .withToolObject(new ParkingTooling())
      .withToolCallInspectors(new ToolCallLoggingInspector(LogLevel.INFO, logger));
    streamParkingRecommendationsWithThinking(runner, TOOL_PARKING_PROMPT);
}

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreamingWithThinkingAndTooling_thenReceivesRecommendationAndReasoning

12:48:52.342 [HttpClient-4-Worker-0] WARN  StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
12:48:53.275 [boundedElastic-2] INFO  StreamingWithThinkingAndToolingIntegrationTest - beforeToolCall: tool=reserveGarage, argsLength=28
12:48:53.278 [boundedElastic-2] INFO  Embabel - [suspicious_tharp] calling tool reserveGarage({"arg0":"Midtown Manhattan"})
12:48:53.281 [boundedElastic-2] INFO  Embabel - [suspicious_tharp] tool reserveGarage returned Garage reserved near Midtown Manhattan ($30/hour, guaranteed) in 2ms with payload {"arg0":"Midtown Manhattan"}
12:48:53.284 [boundedElastic-2] INFO  StreamingWithThinkingAndToolingIntegrationTest - afterToolCall: tool=reserveGarage, status=Text, resultLength=61, durationMs=6
12:48:55.299 [boundedElastic-3] INFO  StreamingWithThinkingAndToolingIntegrationTest - beforeToolCall: tool=findStreetParking, argsLength=38
12:48:55.299 [boundedElastic-3] INFO  Embabel - [suspicious_tharp] calling tool findStreetParking({"arg1":30,"arg0":"Midtown Manhattan"})
12:48:55.300 [boundedElastic-3] INFO  Embabel - [suspicious_tharp] tool findStreetParking returned Street parking found near Midtown Manhattan (free) in 1ms with payload {"arg1":30,"arg0":"Midtown Manhattan"}
12:48:55.300 [boundedElastic-3] INFO  StreamingWithThinkingAndToolingIntegrationTest - afterToolCall: tool=findStreetParking, status=Text, resultLength=50, durationMs=1
12:48:56.953 [boundedElastic-4] INFO  StreamingWithThinkingAndToolingIntegrationTest - beforeToolCall: tool=findMeterParking, argsLength=38
12:48:56.954 [boundedElastic-4] INFO  Embabel - [suspicious_tharp] calling tool findMeterParking({"arg1":30,"arg0":"Midtown Manhattan"})
12:48:56.954 [boundedElastic-4] INFO  Embabel - [suspicious_tharp] tool findMeterParking returned No metered parking found within 30 minutes in 0ms with payload {"arg1":30,"arg0":"Midtown Manhattan"}
12:48:56.954 [boundedElastic-4] INFO  StreamingWithThinkingAndToolingIntegrationTest - afterToolCall: tool=findMeterParking, status=Text, resultLength=42, durationMs=1
12:48:58.801 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: I'll help you find the best parking options for your client meeting in Midtown Manhattan. Let me check all available parking options for you.Based on the parking options available, here are my three recommendations with the best option first:
12:49:00.945 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Advisor needs guaranteed parking for 3-hour meeting in 30 minutes, option=GARAGE, cost=90, summary=Reserve garage parking at $30/hour for 3 hours ($90 total). This is the BEST option because it's guaranteed and ensures you won't be late for your client meeting. With only 30 minutes until the meeting, reliability is critical.
12:49:03.093 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Advisor needs guaranteed parking for 3-hour meeting in 30 minutes, option=STREET, cost=0, summary=Free street parking is available but highly risky. While it costs nothing, finding a spot is uncertain and time-consuming in Midtown Manhattan. Given that arriving late is not acceptable and you only have 30 minutes, this option could jeopardize your meeting.
12:49:03.706 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Advisor needs guaranteed parking for 3-hour meeting in 30 minutes, option=METER, cost=0, summary=Metered parking is NOT available within your 30-minute timeframe in Midtown Manhattan. This option is not viable for your situation.
12:49:05.244 [HttpClient-4-Worker-0] WARN  StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
12:49:05.247 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: **Strong Recommendation: Choose the garage parking.** With only 30 minutes before your client meeting and the absolute requirement not to be late, the $90 guaranteed garage spot is the only responsible choice. The cost is a small price compared to the professional consequences of arriving late to a client meeting.

The post LLM Streaming in the Embabel Agentic AI Framework first appeared on Baeldung.

       

1. Spring and Java

>> JDK 27 and JDK 28: What We Know So Far [infoq.com]

JDK 27 has reached its first RC with compact object headers on by default, G1 as the default collector everywhere, and structured concurrency marching through its seventh preview. The JDK 28 train is already loading up, starting with an incubating Simple JSON API

Also worth reading:

• >> Security Baked Into the JVM: sixteen Subjects on the wire [frankel.ch]
• >> Scripting in small apps: you don’t need a container for a macro [foojay.io]
• >> The Third-Generation GUI Builder: One Workspace for Every Form [foojay.io]
• >> Value Classes Still Need Compiler Sympathy [johan-sjolen.github.io]
• >> Quality Outreach Heads-up – JDK 28: Named Group Information Captured in the TLSHandshake JFR Event [inside.java]
• >> Spring Boot Configuration Management Best Practices [jetbrains.com]

Webinars and presentations:

• >> Episode 67 “Keeping Up With the Java Release Train” [I/O] [inside.java]
• >> A Bootiful Podcast: JRuby lead Charles Nutter [spring.io]

Time to upgrade:

• >> Spring Boot 4.1.1 available now and 4.0.8 [spring.io]
• >> Spring AI 2.0.1 Available Now [spring.io]
• >> Spring Cloud 2025.1.3 (aka Oakwood) has been released [spring.io]
• >> Spring Batch 6.0.5 and 6.1.0-M1 available now [spring.io]
• >> Spring Modulith 2.2 M1, 2.1.1, 2.0.8, and 1.4.13 released [spring.io]
• >> BoxLang 1.16.0 Released! [foojay.io]
• >> Announcing Oracle Jipher 10.37: FIPS 140-3 Cryptography for Java [inside.java]
• >> GraalVM Community 25 Innovation 3 (graal 25.3.4.1) [github.com/graalvm]
• >> Quarkus 3.39.1 and 3.39.0 [github.com/quarkusio]
• >> Elasticsearch 9.5.2 [github.com/elastic]
• >> Grails 7.2.3, 7.1.6 and 7.0.16 [github.com/apache]
• >> Micronaut Core 5.1.12 [github.com/micronaut-projects]
• >> Azul Payara Community 7.2026.8 [github.com/payara]
• >> Micrometer 1.17.1 and 1.16.7 [github.com/micrometer-metrics]

2. Technical & Musings

>> Netflix Conductor: The Next Chapter [netflixtechblog.com]

Netflix open-sourced Conductor back in 2016, and this post traces its evolution into a mature orchestration engine — plus what’s next for the project now that it has a dedicated maintainer team and a renewed roadmap. Good context for anyone running workflow orchestration at scale.

Also worth reading:

• >> Fast and Hard Code [pocoo.org]
• >> Your First Virtual Machine: Write yourself a compiler, Part IV [nurkiewicz.com]
• >> Human-in-the-loop Authorization Patterns for Agents [christianposta.com]
• >> Find Git Commits by Commit Message Text [hamvocke.com]
• >> This Fact About KPIs May Surprise You [satisfice.com]
• >> Why agentic AI starts with legacy modernisation by Suzanne Angell [scottlogic.com]
• >> A Tale of Two Flink Autoscalers [netflixtechblog.com]
• >> Some reflections after a year with AI [tfnico.com]
• >> Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy, SMB Multichannel, and Surprising Performance Traps [hanselman.com]
• >> A Cautionary Tale About Data Breach Claims, Verification and Carhartt [troyhunt.com]

3. Pick of the Week

JetBrains is bringing IntelliJ IDEA Conf back in just one week, on September 8–9, 2026.

A free, fully virtual conference for developers working across the Java and JVM ecosystem:

>> IntelliJ IDEA Conf 2026 [jetbrains.com]

The post Java Weekly, Issue 661 first appeared on Baeldung.

       

1. Overview

When working with JSON in Java, Jackson usually handles Java 8 date and time types without much configuration. Yet, we can still encounter problems such as one of the common deserialization parse errors:

JSON parse error: Can not construct instance of java.time.LocalDate:
no String-argument constructor/factory method to deserialize from String value

In newer Jackson versions, the error text takes another form:

Cannot deserialize value of type java.time.LocalDate from String

Although the wording differs slightly, both errors indicate that Jackson is unable to convert the JSON value into a LocalDate or LocalDateTime.

In this tutorial, we’ll explore the JSON deserialization exception and ways around it. First, we demonstrate the issue with an example. After that, we go through different reasons for the problem at hand and how they can be addressed.

2. Understanding the Problem

Let’s write a basic User class:

public class User {
    private String name;
    private LocalDate dob;
    // getters and setters
}

Now, let’s assume we receive a matching JSON:

{
  "name": "x",
  "dob": "2006-06-06"
}

Instead of successfully deserializing the JSON, Jackson throws an exception similar to:

Can not construct instance of java.time.LocalDate:
no String-argument constructor/factory method to deserialize from String value

Notably, the JSON data appears to be valid, because the date already follows the ISO-8601 format expected by LocalDate. The problem usually isn’t the JSON itself but the configuration of Jackson. In fact, the root cause may be a missing Java Time module, an unsupported date format, or using the wrong Java date-time type for the incoming JSON.

3. Verify Jackson Version

Support for the Java Time API has evolved considerably across Jackson releases. Before delving into specific technical issues and code changes, we might consider the versions we’re using.

In Jackson 2.x, Java Time support is provided by the separate jackson-datatype-jsr310 module. In Jackson 3.x, this support is built into jackson-databind, so separate module registration isn’t required.

If the project uses an outdated Jackson version, upgrading Jackson may resolve deserialization issues without any code changes. When it comes to Jackson 2.x, we should also verify that the Java Time module is present and properly configured.

4. Ensure Java Time Support

The most common cause for the JSON error is that the Jackson configuration doesn’t support the Java 8 Date and Time API.

Unlike older types such as java.util.Date, classes like LocalDate, LocalDateTime, and Instant are provided through the Jackson Java Time module.

If this module is missing, Jackson attempts to instantiate LocalDate like a regular Java object. Since LocalDate has no default constructor or string constructor, deserialization fails.

So, assuming we decide on Jackson 2.x, let’s include the Java Time module dependency:

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-jsr310</artifactId>
    <version>2.22.1</version>
</dependency>

If an ObjectMapper is created manually, it should register the module:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());

Still, Spring Boot performs this registration automatically when the module is present on the classpath.

5. Match JSON Date Format

Another common cause for JSON deserialization errors is the exact date format. If the incoming JSON doesn’t use the default ISO-8601 format expected by LocalDate and LocalDateTime, we might see an error.

For example, let’s see a JSON string that can’t be parsed automatically:

{
  "time": "10/20/2020 10:00:10 AM"
}

With the Java Time module registered, Jackson expects an ISO-8601 date-time for a LocalDateTime field by default:

2020-10-20T10:00:10

In such cases, when the JSON data uses another format, the field should specify the expected pattern:

public class ImportTrans {
    @JsonFormat(pattern = "M/d/yyyy h:mm:ss a")
    private LocalDateTime time;
}

However, this example also contains another hint. The JSON data can actually contain both a date and a time, while Java LocalDate fields only store a date.

6. Correct Java Time Type

LocalDate represents only a calendar date. In particular, it doesn’t contain any information about time of the day.

If the JSON data includes hours, minutes, or seconds, LocalDate is no longer the appropriate target type:

private LocalDate time;

Instead, we should probably use LocalDateTime:

private LocalDateTime time;

Furthermore, the matching format can then be declared with @JsonFormat:

@JsonFormat(pattern = "M/d/yyyy h:mm:ss a")
private LocalDateTime time;

Choosing the Java type that accurately represents the JSON payload is often the simplest solution.

7. LocalDateTime Has Similar Requirements

The same type of exception frequently appears when using LocalDateTime:

Can not deserialize value of type
java.time.LocalDateTime from String

Let’s consider the following JSON:

{
  "creationTime": "2016-06-16 06:56:00"
}

Same as before, since this format differs from the default ISO-8601 representation, Jackson requires an explicit pattern:

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime creationTime;

The ObjectMapper must also have the Java Time module registered, while the explicit pattern is still required for this non-ISO format.

8. Comparison

Now that we know different reasons for errors around parsing JSON with date-time values with Jackson, let’s see an overview of what we found out:

So, we can check the reference table whenever we encounter an unexpected error.

9. Conclusion

In this article, we explored the error stating that Jackson can’t construct an instance of LocalDate or LocalDateTime.

Specifically, we established that it generally indicates Jackson can’t determine how to convert the incoming JSON into a Java date-time object.

In conclusion, once the Java type, JSON payload format, and Jackson configuration are aligned, such deserialization errors should disappear and Java Time types should be handled transparently.

The post How to Fix Jackson JSON Parse Error Can not construct instance of java.time.LocalDate first appeared on Baeldung.

       

1. Introduction

In this tutorial, we’ll look at Microcks, an open-source, Kubernetes-native platform for turning API and microservices contracts into live mocks. We’ll also see how to reuse the same contracts to run conformance tests against a real implemenation.

We’ll cover the core concepts first, then use the Testcontainers integration to spin up Microcks inside a JUnit5 test, import an OpenAPI contract, call the generated mock, and validate a running service against it.

2. What Is Microcks?

Microcks is a CNCF (Cloud Native Computing Foundation) project for API mocking and testing. It consumes API and microservice artifacts, such as OpenAPI specs, AsyncAPI specs, gRPC protobuf files, GraphQL schemas, Postman collections, and SoapUI projects. Then, it turns them into live, stateful mocks in seconds.

Beyond mocking, Microcks reuses these same artifacts to run contract conformance and non-regression tests against a real API implementation. It also integrates with Jenkins, GitHub Actions and Tekton pipelines through a CLI, so both mocking and testing can be automated across the whole delivery chain.

We can run Microcks as a standalone server, using Docker Compose or a Kubernetes/Helm deployment. For local development and CI, though, it’s more convenient to embed it directly inside a test using the Testcontainers module.

Microcks isn’t limited to synchronous REST APIs, either. Through its ensemble mode, it can also mock and contract-test SOAP, GraphQL, and gRPC services, as well as event-driven APIs described with AsyncAPI, over brokers like Kafka, SQS or SNS. That means the same tool and the same workflow can cover most of the API styles a typical microservices architecture is likely to use.

3. Setting Up Microcks With Testcontainers

The microcks-testcontainers library lets us start a lightweight, throwaway Microcks instance for the lifetime of a test class.

First, let’s add the Maven dependency:

<dependency>
    <groupId>io.github.microcks</groupId>
    <artifactId>microcks-testcontainers</artifactId>
    <version>0.4.4</version>
</dependency>

Next, let’s create and start a MicrocksContainer, pointing it to an OpenAPI contract for our API:

MicrocksContainer microcks = new MicrocksContainer(
  DockerImageName.parse("quay.io/microcks/microcks-uber:1.14.0"))
  .withMainArtifacts("apipastries-openapi.yaml");
microcks.start();

The uber image bundles everything Microcks needs without an external MongoDB dependency, which keeps startup fast. We can also import artifacts after startup, using importAsMainArtifact() or importAsSecondaryArtifact() on the running container.

4. Mocking the API

Once the container has imported the contract, Microcks automatically exposes a mock endpoint for every operation. We can retrieve the base URL and call it like any real API:

String baseApiUrl = microcks.getRestMockEndpoint("API Pastries", "0.0.1");
HttpResponse<String> response = client.send(
  HttpRequest.newBuilder(URI.create(baseApiUrl + "/pastries/Millefeuille")).GET().build(),
  HttpResponse.BodyHandlers.ofString());
assertEquals(200, response.statusCode());

Microcks generates realistic responses straight from the examples defined in the OpenAPI contract. Then, it cycles through them so repeated calls don’t always return the same payload. This means consumers can be developed and tested against a dependency that doesn’t exist yet, or isn’t reacheable from a test environment.

Furthermore, there are ways we can confirm a mock was actually called. We’ll do this by either calling microcks.verify(“API Pastries”,”0.0.1″), or by checking the exact invocation count through microcks.getServiceInvocationsCount(“API Pastries”,”0.0.1″).

5. Running Contract Tests

The same contract can validate a real implementation running on our machine. First, we need to expose the port with Testcontainers.exposeHostPorts() before starting the container, not after. We do this since the Microcks container needs to reach back out to our host:

Testcontainers.exposeHostPorts(port);
microcks.start();

Then, let’s launch a conformance test against our locally running server:

TestRequest testRequest = new TestRequest.Builder()
  .serviceId("API Pastries:0.0.1")
  .runnerType(TestRunnerType.OPEN_API_SCHEMA.name())
  .testEndpoint("http://host.testcontainers.internal:" + port)
  .filteredOperations(List.of("GET /pastries/{name}"))
  .timeout(Duration.ofSeconds(2))
  .build();
TestResult testResult = microcks.testEndpoint(testRequest);
assertTrue(testResult.isSuccess());

We scoped the test to a single operation with filteredOperations(). Without it, Microcks also replays the GET /pastries and PATCH /pastries/{name} examples from the contract, which fail against an implementation that doesn’t cover them yet.

Here, Microcks replays every example from the OpenAPI contract against our running application and checks each response against the schema. For a more JUnit-friendly failure report, we can use the Assertions helper instead, Assertions.assertSuccess(testResult);

This single call runs the same conformance check that a CI pipeline would run against a live deployment, only locally and in milliseconds.

6. Conclusion

In this article, we introduced Microcks as a tool for turning API contracts into live mocks and reusing those same contracts for conformance testing. We used its Testcontainers integration to start a throwaway Microcks instance inside a JUnit test, import an OpenAPI contract, call the generated mock, and run a contract test against a live implementation.

Because mocks and tests are dervide from the same source contract, both stay in sync with the API definition. That removes a common source of drift between what an API promises and what it actually does.

As always, the code is available over on Github.

The post API Mocking and Testing With Microcks first appeared on Baeldung.

       

1. Introduction

It’s sometimes useful to limit the remote addresses that an HTTP client is permitted to call. It helps prevent applications from connecting to unintended destinations and provides an effective defense against Server-Side Request Forgery (SSRF) attacks. To limit the address that an HTTP client can call, we can use an InetAddressFilter. The filter determines which addresses are allowed for outgoing requests. In this tutorial, we’ll explore how to use the InetAddressFilter class in a Spring-based application.

2. Understanding SSRF in the Context of HTTP Clients

SSRF is a critical security vulnerability that allows an attacker to force a server to make requests to unintended locations. These requests may target internal systems, cloud metadata endpoints, or loopback addresses. To demonstrate how SSRF can occur in an HTTP client, let’s consider a simple endpoint that accepts a URL and uses RestClient to retrieve its contents:

@GetMapping("/fetch")
public String fetch(@RequestParam String url) {
    return restClient.get()
      .uri(url)
      .retrieve()
      .body(String.class);
}

The endpoint accepts a URL as a request parameter and forwards it to RestClient. The intention is to allow users to retrieve content from public URLs. For example, a legitimate request might look like:

curl --location http://127.0.0.1:8080/fetch?url=https://www.baeldung.com

However, an attacker could provide a URL that points to an internal resource instead:

curl --location http://127.0.0.1:8080/fetch?url=admin

Instead of contacting a public website, our server now makes requests to its own internal network. This can expose internal admin APIs, databases, Kubernetes services, etc. This class of vulnerability is known as SSRF. Historically, mitigating SSRF in Spring Boot applications required custom ClientHttpRequestInterceptor implementations or complex network-level firewalls. Spring Boot 4.1.0 introduces first-class support for SSRF mitigation via the InetAddressFilter interface.

3. Maven Dependency

Let’s start by importing the spring-boot-starter-restclient dependency to our pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-restclient</artifactId>
    <version>4.1.1-SNAPSHOT</version>
</dependency>

4. Introducing InetAddressFilter

The InetAddressFilter interface is a functional interface. Unlike validating the hostname or URL, InetAddressFilter performs its checks after DNS resolution. Spring Boot provides several built-in filters for common scenarios, such as allowing only public addresses (InetAddressFilter.externalAddresses()) or blocking special-purpose network ranges (InetAddressFilter.internalAddresses()). We can combine these filters using logical operators:

InetAddressFilter.of("192.168.0.0/16")
  .andNot("192.168.1.100");

The API also supports and(), or(), and negate() for composing more complex rules:

InetAddressFilter.externalAddresses()
  .or(InetAddressFilter.of("10.20.0.0"));

This enables expressive allowlists and blocklists without custom networking code.

5. Applying the Filter Globally

The simplest and most common approach is to declare an InetAddressFilter bean. Spring Boot then automatically applies it to every auto-configured HTTP client builder (RestClient, WebClient, RestTemplate, etc.). Let’s configure the InetAddressFilter to allow connections only to external IP addresses:

@Configuration(proxyBeanMethods = false)
public class HttpClientSecurityConfig {
    @Bean
    public InetAddressFilter httpClientInetAddressFilter() {
        return InetAddressFilter.externalAddresses();
    }
}

With this single bean, any client created from the auto-configured builders will reject requests whose resolved address is not external. Now, we can create a RestClient without any additional security configuration:

@Bean
RestClient restClient(RestClient.Builder builder) {
    return builder.build();
}

Because the RestClient.Builder has already been customized by Spring Boot, the resulting RestClient automatically uses the configured InetAddressFilter. As a result, any request whose resolved destination is not an external address—for example, a loopback or private IP address—is rejected before a connection is established. This approach centralizes the application’s outbound network policy in a single place and ensures that all auto-configured HTTP clients consistently enforce the same SSRF protection.

6. Applying the Filter Per-Client

In some scenarios, applying a global InetAddressFilter may be too restrictive. For example, an application might communicate with both public APIs and specific internal services, each requiring different outbound access rules. In such cases, we can apply an InetAddressFilter to an individual HTTP client by configuring the underlying HttpClientSettings when creating the client. Let’s create a RestClient that only allows requests to external addresses:

@Bean
RestClient restClient(RestClient.Builder builder) {
    InetAddressFilter onlyExternalAddresses = InetAddressFilter.externalAddresses();
    HttpClientSettings settings = HttpClientSettings.defaults()
      .withInetAddressFilter(onlyExternalAddresses);
    ClientHttpRequestFactory requestFactory = ClientHttpRequestFactoryBuilder
      .jdk().build(settings);
    return builder
      .requestFactory(requestFactory)
      .build();
}

Here, the filter is attached only to this specific RestClient instance. Other HTTP clients in the application can use different security policies or remain unaffected. This approach is useful when different integrations have different network requirements. For example, a client used to call third-party APIs can be restricted to public addresses, while another client used for communication with trusted internal services can use a more specific allowlist. By configuring the filter at the client level, we can apply fine-grained outbound request controls without changing the behavior of the entire application.

7. Test

To verify that the configured InetAddressFilter is applied, we can write a unit test that uses the configured RestClient bean to access a loopback address. The application is configured with InetAddressFilter.externalAddresses(), which permits only publicly routable IP addresses. Since 127.0.0.1 is a loopback address, the request is rejected before an HTTP connection is established. Let’s create a test case:

@Test
void whenCallingLoopbackAddress_thenFilteredHostExceptionIsThrown() {
    assertThatThrownBy(() ->
        restClient.get()
          .uri("https://127.0.0.1:8080")
          .retrieve()
          .toBodilessEntity()
    ).isInstanceOf(FilteredHostException.class)
     .hasMessageContaining("127.0.0.1");
}

When the test executes, the RestClient resolves the destination host and passes the resulting InetAddress to the configured InetAddressFilter. Because the address does not satisfy the externalAddresses() policy, Spring Boot throws a FilteredHostException and aborts the request before opening a network connection.

8. Conclusion

In this tutorial, we explored how SSRF can affect applications that make outbound HTTP requests based on user-controlled input. We also looked at how Spring Boot 4.1 simplifies SSRF mitigation with InetAddressFilter. It allows applications to validate the resolved destination address before establishing an outbound connection. The feature integrates with Spring’s HTTP client infrastructure, including both blocking and reactive clients, and provides a flexible API for composing allowlists and blocklists. By applying InetAddressFilter, we can enforce outbound network access policies at the HTTP client level. This reduces the risk of unauthorized access to internal resources while keeping the application code clean and maintainable.

As always, the source code is available over on GitHub.

The post HTTP Client SSRF Mitigation with InetAddressFilter in Spring Boot first appeared on Baeldung.

       

1. Introduction

In this tutorial, we’ll take a look at db-scheduler, a simpler alternative to Quartz. We’ll see what it is, how to use it and what we can do with it.

2. What Is DB-Scheduler?

DB-Scheduler is a cluster-aware, persistent scheduling library. It’s designed to be simple to include in our application. Our only requirements are Java 17+ and a JDBC connection to a database with a single database table in which we store and manage our tasks.

Using db-scheduler, we can easily support:

• One-time tasks: tasks that are scheduled to run once at a specific point in time
• Simple recurring tasks: tasks that are set up to run on a statically defined regular schedule
• Dynamic recurring tasks: tasks that run on a regular schedule, but that we can schedule dynamically at runtime

The db-scheduler library will then handle everything for us. This includes ensuring that these jobs run correctly across a cluster of services without dropping them or running them multiple times.

3. Setting Up

Before we can use db-scheduler, we need to first set it up in our application. This includes adding it to our project and getting it running.

3.1. Dependencies

Before using db-scheduler, we need to include the latest version in our build, which is 16.12.0 at the time of writing.

If we’re using Maven, we can include this dependency in our pom.xml file:

<dependency>
    <groupId>com.github.kagkarlsson</groupId>
    <artifactId>db-scheduler</artifactId>
    <version>16.12.0</version>
</dependency>

This will bring in everything that we need to be able to use it in our application. The only required dependencies are JSpecify and SLF4J – everything else is self-contained.

3.2. Database Schema

In order to work, db-scheduler needs a single database table in the database we connect it to. DDL scripts are provided for most major RDBMS engines, though it might work on others as well. For example, to use with PostgreSQL, we’d use DDL like this:

CREATE TABLE scheduled_tasks (
  task_name TEXT NOT NULL,
  task_instance TEXT NOT NULL,
  task_data BYTEA,
  execution_time TIMESTAMP WITH TIME ZONE NOT NULL,
  picked BOOLEAN NOT NULL,
  picked_by TEXT,
  last_success TIMESTAMP WITH TIME ZONE,
  last_failure TIMESTAMP WITH TIME ZONE,
  consecutive_failures INT,
  last_heartbeat TIMESTAMP WITH TIME ZONE,
  version BIGINT NOT NULL,
  priority SMALLINT,
  PRIMARY KEY (task_name, task_instance)
);
CREATE INDEX execution_time_idx ON scheduled_tasks (execution_time);
CREATE INDEX last_heartbeat_idx ON scheduled_tasks (last_heartbeat);
CREATE INDEX priority_execution_time_idx on scheduled_tasks (priority desc, execution_time asc);

This creates our scheduled_tasks table with the expected structure, ready for db-scheduler to use.

3.3. Scheduler

Finally, before we can use db-scheduler, we need to actually set up a Scheduler instance. This is the central class that manages scheduling all of our jobs.

We create an instance of this by providing a DataSource pointing to the database containing our scheduled_tasks table, and a collection of all the tasks that we want to manage. We’ll see later how to create these:

Scheduler scheduler = Scheduler.create(dataSource)
  .startTasks(tasks)
  .registerShutdownHook()
  .build();

This comes with a reasonable set of default configuration values:

• Poll every 10 seconds
• Heartbeat every 5 minutes
• Consider a task dead if it misses 6 heartbeats
• Run jobs across 10 worker threads

And many more. We can configure all of these when we create our scheduler:

Scheduler scheduler = Scheduler.create(dataSource)
  .startTasks(tasks)
  .registerShutdownHook()
  .pollingInterval(Duration.ofSeconds(2))
  .heartbeatInterval(Duration.ofMinutes(2))
  .missedHeartbeatsLimit(10)
  .threads(5)
  .build();

It’s important that multiple instances in the same cluster use at least the same heartbeat settings. If not, db-scheduler might incorrectly consider some jobs to be dead.

Once we have a scheduler, we need to start it running:

scheduler.start();

At this point, the scheduler will now manage all of the tasks assigned to it. This includes ensuring they’re correctly scheduled and running them at the appropriate times.

4. Simple Recurring Tasks

The easiest tasks to work with are simple recurring tasks. For these, we need a unique name, a frequency at which the task runs, and the task itself:

RecurringTask<Void> task = Tasks.recurring("my-hourly-task", FixedDelay.ofHours(1))
  .execute((instance, context) -> {
    LOG.info("Executed!");
  });

If this is a new task that the scheduler has never seen before, it will be scheduled to run immediately. After that, the scheduler will run it according to the provided schedule. In this case, that means 1 hour after the previous iteration finished. We can also use Daily for running at a particular time every day, and CronSchedule for using a more complicated cron expression.

Our task itself is provided as an instance of VoidExecutionHandler<T>, which is itself a functional interface and can be implemented by a lambda if we wish. The only method of this interface takes two parameters:

• TaskInstance<T> instance – Details about this instance of the task. Useful if we’ve got multiple schedules using the same task implementation.
• ExecutionContext context – Details about the executor itself. Useful if we want to access the scheduler itself from within our task.

Note that we have VoidExecutionHandler and RecurringTask<Void> here. This is because our example task is stateless. We can also support stateful tasks, which have an initial state that can be updated as a result of the task executing. However, these are out of the scope of this article.

5. One-Time Tasks

One-time tasks work a bit differently. In this case, we need to distinguish between the task itself and a descriptor that identifies the task:

TaskDescriptor<String> taskDescriptor = TaskDescriptor.of("my-onetime-task", String.class);
Task<String> task = Tasks.oneTime(taskDescriptor)
  .execute((inst, ctx) -> {
    LOG.info("Executed! Custom data {}, Instance {}", inst.getData(), inst.getId());
  });

This task definition accepts some data that we provide when we schedule the task, and can act on that data as appropriate. In this case, the data is a String, but it can be any type that db-scheduler is able to serialize. By default, this uses Java Serialization but db-scheduler also supports other mechanisms, such as Jackson and Gson.

We then need to register the task with our scheduler. However, we do this by passing the task to the Scheduler.create() method so that db-scheduler knows about it but doesn’t immediately start running it:

Scheduler scheduler = Scheduler.create(dataSource, task)
  .build();

At this point, we can run our task at any time using our scheduler and task descriptor:

scheduler.schedule(taskDescriptor.instance(UUID.randomUUID().toString())
  .data("Hello")
  .scheduledTo(Instant.now().plusSeconds(5))
);

Here we have to provide a unique instance ID for our task, and indicate when the task should run. We’ve also provided some data for our task to act on. The scheduler will then ensure that this task runs correctly at the desired time.

6. Dynamic Recurring Tasks

Dynamic recurring tasks are tasks that are registered dynamically at runtime, similar to our one-time tasks. However, once registered, they’ll continue to run on a schedule similar to our simple recurring tasks.

We create and start these exactly the same as for our one-time task, only using Tasks.recurring() instead:

TaskDescriptor<String> taskDescriptor = TaskDescriptor.of("my-dynamic-recurring-task", String.class);
Task<String> task = Tasks.recurring(taskDescriptor, new CronSchedule("*/5 * * * * ?", ZoneId.of("UTC")))
  .execute((inst, ctx) -> {
    LOG.info("Executed! Custom data {}, Instance {}", inst.getData(), inst.getId());
  });
scheduler.schedule(taskDescriptor.instance(UUID.randomUUID().toString())
  .data("Hello")
  .scheduledTo(Instant.now().plusSeconds(15))
);

This will now start our task at the given time and then, once started, it’ll run at the given schedule. In this case, it first runs 15 seconds after the current time, and then every 5 seconds after that.

If we wish, we can schedule as many different instances of these as we need, and they’ll all run on their own schedule without interfering with each other.

7. Use With Spring Boot

If we’re using Spring Boot, db-scheduler provides a starter dependency that we can use:

<dependency>
    <groupId>com.github.kagkarlsson</groupId>
    <artifactId>db-scheduler-spring-boot-4-starter</artifactId>
    <version>16.12.0</version>
</dependency>

If we’re using Spring Boot 4.x then we need to use db-scheduler-spring-boot-4-starter. If we’re still on Spring Boot 3.x then instead it’s db-scheduler-spring-boot-starter.

This will automatically create and start our Scheduler instance as a Spring bean. On doing this, it’ll also automatically discover any tasks that have been created as Spring beans and register them with this scheduler. This means that the only thing we need to do is create the tasks themselves.

If we want to configure the Scheduler in any way, we can do this using properties in our standard way:

db-scheduler.enabled=true
db-scheduler.polling-interval=5s
db-scheduler.heartbeat-interval=2m
db-scheduler.missed-heartbeats-limit=10
db-scheduler.threads=5

Everything else about using db-scheduler, including how we create and schedule tasks, is exactly the same as before. The starter just makes it simpler to get started in the first place.

8. Conclusion

In this article, we took a very quick look at db-scheduler, including how to schedule recurring and one-time tasks. There’s a lot more that we can do with this. Next time we need to manage scheduled jobs for your applications, why not give it a try?

As always, all the code from this article is available over on GitHub.

The post DB-Scheduler: A Persistent, Cluster-Friendly Scheduler for Java first appeared on Baeldung.

       

1. Spring and Java

>> When @Immutable Made All the Difference: A 3.2x Speedup with Hibernate Second-Level Cache [relation.to]

Hibernate’s second-level cache jumps from 286 seconds to 90 seconds when @Immutable, @Cache(READ_ONLY), and field-level @Mutability(Immutability.class) work together. This case study also shows why omitting the JSONB field annotation caused an 8.1x slowdown. Interesting read.

>> JEP 540 Proposed to Target JDK 28 with a Simple JSON API [infoq.com]

JEP 540 is moving toward JDK 28 with an incubating, dependency-free, deliberately-small JSON API for straightforward parsing and generation.

Also worth reading:

• >> Solving Gradle metadata and Renovate integration [frankel.ch]
• >> Introducing BoxLang AI Explorer: A Local Catalog for Every AI Pattern [foojay.io]
• >> Vibe Coding, Maven, and the Dependencies You Didn’t Choose [foojay.io]
• >> Preparing for Change: Safe Switching over Sealed APIs [inside.java]
• >> JDK 21 approaches end-of-permissive license [oracle.com]
• >> Exploring Compose HTML for Server Side Rendering [jetbrains.com]
• >> Renovate: teaching an old dog new tricks [marcphilipp.de]
• >> Writing a Thymeleaf component library – part 4 [wimdeblauwe.com]

Webinars and presentations:

• >> Build Secure AI Chat Applications with BoxLang, RAG, Ollama, and Amazon Bedrock with Dan Card [foojay.io]
• >> Episode 66 “JSON API, Valhalla Progress, LTS PQC” [IJN] [inside.java]
• >> JSON API, Valhalla Progress, LTS PQC – Inside Java Newscast #114 [nipafx.dev]
• >> Spring Office Hours Podcast: S5E20 – The Developer’s Guide to AI with Danny Thompson [spring.io]
• >> A Bootiful Podcast: Redouble AI CTO and founder Andrey Santrosyan [spring.io]

Time to upgrade:

• >> Quarkus 3.38.3 – Maintenance release [quarkus.io]
• >> A2A Java SDK 1.2.0.Final released [quarkus.io]
• >> Quarkus 3.38.2 – Maintenance release [quarkus.io]
• >> Stubborn Contract 0.1.0 released! [toomuchcoding.com]
• >> Apache Hive 4.2.1 [github.com/apache]
• >> Micronaut Core 5.1.11 [github.com/micronaut-projects]
• >> LangChain4j 1.19.0 [github.com/langchain4j]
• >> Helidon 4.5.3 and 3.2.20 [github.com/helidon-io]

2. Technical & Musings

>> Citizens Build, Agents Execute, Experts Govern [martinfowler.com]

AI agents are making it dramatically easier to build working software, but enterprise delivery still depends on engineering judgment. Of course it does.

Also worth reading:

• >> What Is Reasoning [pocoo.org]
• >> Compiling to intermediate representation: Write yourself a compiler, Part III [nurkiewicz.com]
• >> Idempotent Write Paths: Keeping an Integration Pipeline Correct When Messages Repeat [foojay.io]
• >> Lessons Learned from Fixing Flaky Tests with Claude [henrikwarne.com]
• >> Practitioner Voice: The Writing Category Nobody has Named Yet [martinfowler.com]
• >> How to take incremental steps towards data democratisation by Andy Scotland [scottlogic.com]
• >> AI success depends on data foundations by James Heward [scottlogic.com]
• >> Behind the Scenes: Evolving Netflix’s Ads Event Pipeline for Live – Part II [medium.com]

3. Pick of the Week

>> The Bedrock of Software Design [alex.draftist.io]

The post Java Weekly, Issue 660 first appeared on Baeldung.

       

1. Spring and Java

>> Evolving a Java MCP Server During MCP Specification Upgrades [inside.java]

A practical guide to evolving a Helidon-based Java MCP server to the stateless. Header-based routing and a temporary adapter keep older clients working while tests exercise both protocol paths. Good stuff.

>> Project Valhalla’s First Preview: JEP 401 Redefines == for Java Objects [infoq.com]

JEP 401 brings identity-free value classes and records to preview, changing == for value objects while identity classes retain reference semantics. Good weekend read.

Also worth reading:

• >> Security Baked Into the JVM: two Subjects, one call [frankel.ch]
• >> DuckDB in Spring Batch: Replace In-Memory Java Loops with One SQL Statement [foojay.io]
• >> Push V3: One Message From Your Server to Every Surface [foojay.io]
• >> Embedding DuckDB in a Maven App (and Using It for Things That Aren’t Databases) [foojay.io]
• >> The Power of JDK Flight Recorder: Efficient Profiling and Troubleshooting for Java Applications [inside.java]
• >> Post-Quantum Cryptography in Long-Term Support JDK Releases [inside.java]
• >> How to Use AI Agents in IntelliJ IDEA With ACP [jetbrains.com]
• >> Top 5 AI Features in IntelliJ IDEA [jetbrains.com]
• >> Agent Skills in IntelliJ IDEA [jetbrains.com]
• >> Writing a Thymeleaf component library – part 3 [wimdeblauwe.com]

Webinars and presentations:

• >> Episode 65 “Embracing Virtual Threads with Helidon” [I/O] [inside.java]
• >> Quarkus Insights #256: What is Floci? [quarkus.io]
• >> A Bootiful Podcast: Data guru Gregory Green on RabbitMQ, Valkey, Gemfire, Data Flow, and more [spring.io]

Time to upgrade:

• >> IntelliJ IDEA 2026.2.1 Is Out! [jetbrains.com]
• >> Gradle 9.7.0 [github.com/gradle]
• >> Eclipse Vert.x 4.5.32 [github.com/eclipse-vertx]
• >> Elasticsearch 9.5.1 and 9.4.5 and 8.19.20 [github.com/elastic]
• >> Netflix Zuul 4.1.4 [github.com/Netflix]
• >> Apache Camel 4.18.4 and 4.14.9 and 4.22.0 [github.com/apache]

2. Technical & Musings

>> Informing HTTP Extension Design with Data [mnot.net]

Mark Nottingham tests HTTP extensions against 120 million Common Crawl responses. The results show how invisible failures and weak migration incentives undermine adoption, yielding a practical lesson: design for repeatable deployment, make errors visible, and study real usage before extending a protocol.

Also worth reading:

• >> Programming Language Migration 2025: Why Developers Switch [jetbrains.com]
• >> One required check to rule them all [marcphilipp.de]
• >> Vertical slices, their ownership and external dependencies [event-driven.io]
• >> TDD inside the agent loop – theater or actual value? [martinfowler.com]
• >> Unlocking your data: the value is in collaboration [scottlogic.com]
• >> Agile Leadership [scottlogic.com]
• >> How to accelerate agentic adoption [scottlogic.com]
• >> How and Why Netflix Built a Real-Time Distributed Graph: Part 3 – Querying the graph with gRPC [netflixtechblog.com]

3. Pick of the Week

>> Things you didn’t know about indexes [jon.chrt.dev]

The post Java Weekly, Issue 659 first appeared on Baeldung.

       

Comments

• In reply to Vincent. Hey, Vincent. Thanks for the feedback. ... by Ulisses Lima
• You have encoding prolem on your URL : with Helidon†... by Vincent