1. Overview

Starting with version 9, Java places a strong emphasis on encapsulation. The major feature behind this is the Java Platform Module System (JPMS). It controls how our own packages are exposed and, at the same time, restricts access to Java’s internal classes. However, many libraries rely heavily on reflection to access private members. So we need ways to relax these restrictions in a controlled manner.

In this tutorial, we’ll learn how to avoid the InaccessibleObjectException when deserializing JSON with Gson. We’ll focus on modular projects and date handling.

2. Gson Status

Gson offers convenient tools for serializing objects to JSON and deserializing them back, and it relies on accessing private fields via reflection. With strong encapsulation in place, this no longer works seamlessly, either for our own objects or for Java’s internal classes. The latest Gson versions have made a small move towards public APIs, specifically for records and dates.

Gson is currently in maintenance mode. Therefore, we shouldn’t expect any new features, only bug fixes and security fixes.

3. Project Setup

Let’s examine the pom.xml we’ll use. We need Java 17 to demonstrate strong encapsulation and for its full support of records. Therefore, we set it in the properties section of pom.xml:

<maven.compiler.release>17</maven.compiler.release>

Next, let’s check the Gson version. We should use the latest one:

<dependency>
    <groupId>com.google.code.gson</groupId>
    <artifactId>gson</artifactId>
    <version>2.14.0</version>
</dependency>

4. Gson and Java Modules

Let’s create a simple Java project named gson-module. We declare the gson.exception module in the module-info.java file:

module gson.exception {
    requires com.google.gson;
    requires org.slf4j;
    exports gson.exception;
}

With the requires statement, we state that our module needs Gson (and SLF4J for logging). Then, we make our own package gson.exception available to other modules with the exports statement.

Now let’s add some classes that describe a conference. The first is a good old POJO:

public class ConferencePojo {
    private String name;
    private int numberOfParticipants;
    // standard setters and getters
}

This object stores the name and number of participants of a conference. It has private fields and public getters and setters.

Next, we prepare an equivalent Java record:

public record ConferenceRecord(String name, int numberOfParticipants) {
}

With a record, we don’t need to declare the fields or write getters and setters.

4.1. Gson Failure With POJO

Gson easily deserializes a POJO such as ConferencePojo in a classpath project, but not in a module path one. To prove that, we’ll run the GsonModuleMain application inside our modular project. Let’s look at its main method:

public static void main(String[] args) {
    String moduleName = GsonModuleMain.class.getModule()
      .getName();
    if (moduleName == null) {
        log.info("Mode: [ Class Path ] (Class in the Unnamed Module)");
    } else {
        log.info("Mode: [ Module Path ] - Module name: " + moduleName);
    }
    Gson gson = new Gson();
    String json = "{\"name\":\"Java Conference\"}";
    try {
        ConferencePojo pojo = gson.fromJson(json, ConferencePojo.class);
        log.info("Deserialization successful! Object " + pojo);
    } catch (Exception e) {
        log.error("Expected exception caught!", e);
    }
}

At the beginning, we log whether the JVM actually loaded our class from the module path. Then we try to deserialize the POJO. Let’s examine the result:

10:40:06.766 [main] INFO gson.exception.GsonModuleMain -- Mode: [ Module Path ] - Module name: gson.exception
10:40:06.868 [main] ERROR gson.exception.GsonModuleMain -- Expected exception caught!
com.google.gson.JsonIOException: Failed making field 'gson.exception.ConferencePojo#name' accessible; either increase its visibility or write a custom TypeAdapter for its declaring type.
See https://github.com/google/gson/blob/main/Troubleshooting.md#reflection-inaccessible-to-module-gson
...
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private java.lang.String gson.exception.ConferencePojo.name accessible: module gson.exception does not "opens gson.exception" to module com.google.gson
...

Gson throws a JsonIOException caused by an InaccessibleObjectException. From the two messages, we learn what happened and get hints on how to solve the problem. In short, within a modular project, Gson can’t access the private fields of our class unless we let it.

4.2. Success With Records

With records, we’ll get a completely different result. Let’s use a JUnit 5 test to demonstrate it:

@Test
void givenModularAndExportedPackage_whenDeserializingRecord_thenSuccess() {
    String json = """
        {
            "name": "Java Conference",
            "numberOfParticipants": 150
        }
        """;
    Gson gson = new Gson();
    ConferenceRecord result = assertDoesNotThrow(() -> {
        return gson.fromJson(json, ConferenceRecord.class);
    });
    assertNotNull(result);
    assertEquals("Java Conference", result.name());
}

This time, Gson successfully deserializes the JSON and creates the record. Since version 2.10, Gson uses a record’s canonical constructor when instantiating the object, unlike classes, where Gson needs access to private fields.

5. How to Deserialize a POJO

If we still want to use a POJO, let’s follow the hints from the exception messages. We have four ways to fix this.

5.1. Make Fields Public

Let’s create a copy of ConferencePojo with public fields:

public class ConferencePojoPublic {
    public String name;
    public int numberOfParticipants;
}

Now Java lets Gson access the fields with reflection, and deserialization succeeds. However, we lose encapsulation this way.

5.2. opens to Expose Private Fields

To let Gson work with our private fields, we can open our package to it. Let’s create a new project, gson-module-opens, and look at its module-info.java file:

module gson.exception {
    requires com.google.gson;
    requires org.slf4j;
    opens gson.exception to com.google.gson;
    exports gson.exception;
}

With the statement opens gson.exception to com.google.gson, we allow Gson to access the private fields in the gson.exception package. Let’s run our GsonModuleMain application again:

19:08:55.369 [main] INFO gson.exception.GsonModuleMain -- Mode: [ Module Path ] - Module name: gson.exception
19:08:55.410 [main] INFO gson.exception.GsonModuleMain -- Deserialization successful! Object gson.exception.ConferencePojo@675d3402

This time, the program doesn’t throw an exception and deserializes the JSON successfully, even in the modular project.

5.3. Using the TypeAdapter Abstract Class

If we can’t use opens, we can extend Gson’s TypeAdapter abstract class for our POJO. All we need to do is implement its write and read methods. As we focus on deserialization, let’s look only at the read method:

@Override
public ConferencePojo read(JsonReader in) throws IOException {
    String name = null;
    int numberOfParticipants = 0;
    in.beginObject();
    while (in.hasNext()) {
        String key = in.nextName();
        if ("name".equals(key)) {
            name = in.nextString();
        } else if ("numberOfParticipants".equals(key)) {
            numberOfParticipants = in.nextInt();
        } else {
            in.skipValue();
        }
    }
    in.endObject();
    ConferencePojo result = new ConferencePojo();
    result.setName(name);
    result.setNumberOfParticipants(numberOfParticipants);
    return result;
}

The read method returns an instance of ConferencePojo. It loops over all the entries of the JsonReader and picks out the fields by their JSON names.

Note that we create the ConferencePojo object with its default constructor and fill it in with setters. This is the crucial point: to use a TypeAdapter, we need a public API for creating the object. In our case, that’s the setters, but a constructor, public fields, a factory, or a builder would work as well.

Now let’s test the adapter:

@Test
void whenAdapterForPojo_thenSuccess() {
    Gson gson = new GsonBuilder()
      .registerTypeAdapter(ConferencePojo.class, new ConferencePojoAdapter())
      .create();
    String json = """
        {
            "name": "Java Conference",
            "numberOfParticipants": 100
        }
        """;
    ConferencePojo result = gson.fromJson(json, ConferencePojo.class);
    assertNotNull(result);
    assertEquals("Java Conference", result.getName());
}

Note that we need to register the adapter with GsonBuilder.

5.4. The –add-opens Argument as a Last Resort

When we can’t modify the module’s source code, we still have one option left. We can open the package when the program starts by passing the –add-opens argument to the JVM. Let’s look at the argument for our gson-module project, which doesn’t open its package:

--add-opens gson.exception/gson.exception=com.google.gson

Starting from the left, we have the module name gson.exception, as declared in the module-info.java file. Next comes the package we want to open, gson.exception. Finally, we name the module we grant the access to, com.google.gson.

This is the launch-time equivalent of the opens statement, and with it, GsonModuleMain from gson-module deserializes the POJO successfully. However, we should treat it as a last resort, since the argument lives outside the code and we have to repeat it in every launch configuration. Our article on illegal reflective access covers the background in more detail.

6. Gson and Time

Besides problems with modular projects, we can run into the same exception when deserializing JSON into the date and time classes from the java.time API, such as LocalDate, Instant, or Duration. With strong encapsulation and an older Gson version, we get a JsonIOException with the message “Failed making field ‘java.time.LocalDate#year’ accessible”, again caused by an InaccessibleObjectException. This time, Gson tries to reach the private fields of a Java internal class. Moreover, we can’t solve this problem with the opens statement, as it can only open our own packages, not Java’s internals. However, Gson 2.14.0 has restored support for these classes.

6.1. LocalDate and Structured JSON

Let’s add a conferenceStart field in a new ConferencePojoWithDate class. We’re continuing in the gson-module-opens project, as the other fields are private:

public class ConferencePojoWithDate {
    private String name;
    private int numberOfParticipants;
    private LocalDate conferenceStart;
    // standard setters and getters
}

Now let’s prepare the JSON. We need to use a nested structure for conferenceStart:

{
    "name": "Java Conference",
    "numberOfParticipants": 500,
    "conferenceStart": {
        "year": 2026,
        "month": 8,
        "day": 17
    }
}

Note that the keys year, month, and day exactly match the names of the private fields of LocalDate. The same is true for the other time classes. For example, for Duration, the nested JSON provides the seconds and nanoseconds and looks like this:

"duration": {
    "seconds": 7200,
    "nanos": 0
}

Gson kept this naming convention for backward compatibility. It doesn’t (and isn’t allowed to) access the private fields of Java’s internal classes anymore. Instead, the authors implemented built-in TypeAdapters that use the public java.time API to transfer the data.

We should be especially careful to use the correct field names. If Gson doesn’t find a matching key in the JSON, it silently falls back to the default value of zero. For LocalDate, a zero month then triggers a completely different exception, a DateTimeException from the date validation in java.time.

Next, we can’t deserialize a date in ISO format out of the box. So, a plain string value such as the following fails with a JsonSyntaxException:

"conferenceStart":"2026-08-17"

To handle dates encoded as strings, we need to implement a custom TypeAdapter.

Finally, let’s emphasize that the same rules apply to records: we can deserialize nested time structures out of the box, and we need a TypeAdapter otherwise.

7. Conclusion

In this article, we looked at using Gson in modern, modular Java. We saw that it no longer works as easily as it did with Java 8 and the classpath.

We examined the problem in a modular project and looked at several ways to make Gson fit the rules of the JPMS. As our first measure, we made the class fields public. Next, we gave Gson access to private fields with the opens statement, or with the equivalent –add-opens JVM argument.

We then implemented a TypeAdapter that creates the object through its public API. We also saw that Gson works with records out of the box, using their canonical constructors.

Finally, we checked how Gson handles the classes from the java.time package. We noted that the newest version can deserialize nested time objects as expected again.

The bottom line is that we have two main ways to avoid the InaccessibleObjectException. The first is to open our code to Gson’s reflection, and with the opens statement, we can grant that access to Gson only. The second is to switch to records and stay within the rules of the JPMS. In addition, if we have a public API for creating the object, we can implement a TypeAdapter.

The post Gson Deserialization and the InaccessibleObjectException first appeared on Baeldung.

       

1. Introduction

Jackson is a Java library commonly used to convert between Java objects and JSON. During JSON deserialization, Jackson may throw an InvalidDefinitionException when it can’t determine how to create an instance of the target class. This can happen even when the JSON structure matches the class fields.

In this tutorial, we’ll reproduce the exception using Jackson 2.17.2 and explore several ways to resolve it.

2. Reproducing the Exception

Let’s start with an immutable Notification class that contains a parameterized constructor:

public class Notification {
    private final String message;
    private final int priority;
    public Notification(String message, int priority) {
        this.message = message;
        this.priority = priority;
    }
    // getters
}

Next, let’s try to deserialize a JSON object into the Notification class:

String json = "{\"message\":\"Server maintenance\",\"priority\":2}";
ObjectMapper mapper = new ObjectMapper();
mapper.readValue(json, Notification.class);

Although the JSON properties match the fields in Notification, Jackson can’t determine how they map to the constructor parameters. The constructor doesn’t specify which JSON property Jackson should use for each parameter.

As a result, deserialization fails with an InvalidDefinitionException:

Cannot construct instance of `com.baeldung.invaliddefinitionexception.Notification` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)

The exception indicates that Jackson needs a suitable mechanism to create the Notification instance. We can address this in several ways.

3. Adding a Default Constructor

One way to resolve the exception is to provide a no-argument constructor:

public class NotificationWithDefaultConstructor {
    private String message;
    private int priority;
    public NotificationWithDefaultConstructor() {
    }
    // getters and setters
}

By default, Jackson relies on a no-argument constructor to instantiate the target class. It can then populate the object’s properties during deserialization:

NotificationWithDefaultConstructor notification = objectMapper.readValue(json, NotificationWithDefaultConstructor.class);
assertEquals("Server maintenance", notification.getMessage());
assertEquals(2, notification.getPriority());

This approach works well for mutable classes, where Jackson can set the properties after creating the instance.

4. Defining a Property-Based Creator

For immutable classes, we can explicitly define how Jackson should use the parameterized constructor:

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;
public class NotificationWithCreator {
    private final String message;
    private final int priority;
    @JsonCreator
    public NotificationWithCreator(
      @JsonProperty("message") String message, 
      @JsonProperty("priority") int priority) {
        this.message = message;
        this.priority = priority;
    }
    
    // getters
}

In this case, the @JsonCreator annotation tells Jackson to use the annotated constructor to create the object. The @JsonProperty annotations specify which JSON property corresponds to each constructor parameter.

With the constructor configured as a creator, we can deserialize the JSON while keeping the class immutable:

NotificationWithCreator notification = objectMapper.readValue(json, NotificationWithCreator.class);
assertEquals("Server maintenance", notification.getMessage());
assertEquals(2, notification.getPriority());

In addition, we should make sure to import the annotations from the com.fasterxml.jackson.annotation package, which Jackson 3.x also uses. Jackson won’t recognize creator annotations imported from the legacy org.codehaus.jackson package.

4.1. Factory Methods as Creators

Factory methods can also be creators. If Jackson doesn’t recognize our factory method as a creator, it will throw the same InvalidDefinitionException.

To resolve the issue, we annotate the method and its parameters in the same way as we do with parameterized constructors:

@JsonCreator
public static NotificationWithFactory create(
  @JsonProperty("message") String message,
  @JsonProperty("priority") int priority) {
    return new NotificationWithFactory(message, priority);
}

Now, this method can also act as a creator.

5. Discovering Constructor Parameter Names

Finally, instead of adding Jackson annotations to the target class, we can configure Jackson to discover constructor parameter names.

5.1. Using ParameterNamesModule

In Jackson 2.x, we can use ParameterNamesModule to discover constructor parameter names without adding @JsonProperty annotations:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new ParameterNamesModule());
Notification notification = mapper.readValue(json, Notification.class);
assertEquals("Server maintenance", notification.getMessage());
assertEquals(2, notification.getPriority());

We need to compile the class with the Java -parameters option so that the parameter names are available at runtime. In Jackson 3.x, this functionality is built into jackson-databind and enabled by default, so we don’t need to register a separate module.

5.2. Using ParanamerModule

Another option in Jackson 2.x is to use ParanamerModule. First, we need to add the jackson-module-paranamer dependency to our project:

<dependency>
    <groupId>com.fasterxml.jackson.module</groupId>
    <artifactId>jackson-module-paranamer</artifactId>
    <version>${jackson.version}</version>
</dependency>

Next, we register ParanamerModule with the ObjectMapper:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new ParanamerModule());
Notification notification =
    mapper.readValue(json, Notification.class);
assertEquals("Server maintenance", notification.getMessage());
assertEquals(2, notification.getPriority());

Once registered, ParanamerModule gives Jackson the constructor parameter names, so it can match the message and priority to the corresponding JSON properties.

However, Paranamer is discontinued and supports Jackson 2.x only, which limits this approach for newer projects.

6. Conclusion

In this article, we reproduced a Jackson deserialization exception that occurs when Jackson can’t determine how to create the target object. We then explored several approaches to resolve it.

These include adding a default constructor, defining a property-based creator with @JsonCreator and @JsonProperty, and letting Jackson discover constructor parameter names. Static factory methods can also serve as creators.

The post Resolving Exception: Cannot Deserialize From Object Value (No Delegate- Or Property-Based Creator) first appeared on Baeldung.

       

1. Spring and Java

>> From Spec-Driven Development to Living Specifications in Java Projects [foojay.io]

An interesting Java-focused piece exploreing a more durable model: bringing specifications closer to the code so they remain useful, testable, and alive as the system evolves.

Also worth reading:

• >> Acceleration of Curve25519 Field Operations with Java Software and Intrinsics [inside.java]
• >> Debug Past an HTTP 403 Without Breaking Spring Security [jetbrains.com]
• >> Testing your auto-configuration against a missing optional dependency [wimdeblauwe.com]
• >> No Database Operations Found: What Writing a Spring Boot Analyzer Taught Me About Spring [foojay.io]
• >> Masking a JVM thread dump without breaking the analysis [foojay.io]
• >> Bringing Raspberry Pico to Quarkus with Firmata [foojay.io]
• >> Building an Agentic Warehouse Management System – Part One, Part Two, and Part Three [foojay.io]
• >> My Ten Year Quest to Evolve Java Collections Beyond Java Stream [medium.com]

Webinars and presentations:

• >> Principles of Memory Management in Java [inside.java]
• >> Quarkus Insights #258: Quarkus Feature Flags [quarkus.io]
• >> A Bootiful Podcast: BellSoft’s Catherine Edelveis on hardened runtime images, container security, and more [spring.io]

Time to upgrade:

• >> Kotlin 2.4.20 Released [jetbrains.com]
• >> Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More [jetbrains.com]
• >> Quarkus 3.39.2, 3.33.3.2 LTS, 3.27.5.2 LTS – Maintenance releases [quarkus.io]
• >> Spring Tools 5.4.0 released [spring.io]
• >> Jetty 12.1.13 and 12.0.39 [github.com/jetty]
• >> Vert.x 5.1.8 [github.com/eclipse-vertx]
• >> Elasticsearch 9.5.3 [github.com/elastic]
• >> Micronaut Core 5.1.14, 4.10.27, and 3.10.11 [github.com/micronaut-projects]

2. Technical & Musings

>> The oldest architecture in computing [allthingsdistributed.com]

Werner Vogels looks to the brain for a model of how useful agent memory should work. A fascinating argument that the next breakthroughs in trusted, autonomous agents may come from studying the oldest computing architecture we know.

Also worth reading:

• >> Astra for Coding: Why Are We Doing This Again? [lucumr.pocoo.org]
• >> The Lifecycle of LLM-as-a-Judge: Building, Aligning, and Monitoring at Scale [netflixtechblog.com]
• >> Did Your AI Agent Ever Run a Debugger? One JVM Bug, Two Agent Runs [foojay.io]
• >> Build an AI Agent (From Scratch) [frankel.ch]
• >> Latent Powers [lucumr.pocoo.org]
• >> The Evolution of WSL Support in JetBrains IDEs [jetbrains.com]
• >> Beyond Prompting: Context Engineering for Production-Grade AI [infoq.com]
• >> From OpenTelemetry to DuckDB [foojay.io]

3. Pick of the Week

>> How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cache [blog.cloudflare.com]

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

       

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.

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.

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.

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.

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.

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