1. Overview

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

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

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

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

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

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

2. Understanding the Problem

Let’s write a basic User class:

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

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

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

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

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

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

3. Verify Jackson Version

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

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

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

4. Ensure Java Time Support

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

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

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

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

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

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

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

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

5. Match JSON Date Format

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

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

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

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

2020-10-20T10:00:10

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

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

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

6. Correct Java Time Type

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

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

private LocalDate time;

Instead, we should probably use LocalDateTime:

private LocalDateTime time;

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

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

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

7. LocalDateTime Has Similar Requirements

The same type of exception frequently appears when using LocalDateTime:

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

Let’s consider the following JSON:

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

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

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

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

8. Comparison

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

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

9. Conclusion

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

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

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

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

       

1. Introduction

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

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

2. What Is Microcks?

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

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

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

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

3. Setting Up Microcks With Testcontainers

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

First, let’s add the Maven dependency:

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

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

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

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

4. Mocking the API

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

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

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

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

5. Running Contract Tests

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

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

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

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

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

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

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

6. Conclusion

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

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

As always, the code is available over on Github.

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

       

1. Introduction

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

2. Understanding SSRF in the Context of HTTP Clients

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

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

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

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

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

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

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

3. Maven Dependency

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

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

4. Introducing InetAddressFilter

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

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

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

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

This enables expressive allowlists and blocklists without custom networking code.

5. Applying the Filter Globally

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

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

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

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

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

6. Applying the Filter Per-Client

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

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

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

7. Test

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

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

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

8. Conclusion

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

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

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

       

1. Introduction

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

2. What Is DB-Scheduler?

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

Using db-scheduler, we can easily support:

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

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

3. Setting Up

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

3.1. Dependencies

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

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

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

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

3.2. Database Schema

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

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

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

3.3. Scheduler

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

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

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

This comes with a reasonable set of default configuration values:

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

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

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

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

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

scheduler.start();

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

4. Simple Recurring Tasks

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

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

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

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

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

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

5. One-Time Tasks

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

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

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

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

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

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

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

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

6. Dynamic Recurring Tasks

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

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

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

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

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

7. Use With Spring Boot

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

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

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

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

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

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

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

8. Conclusion

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

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

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

       

1. Spring and Java

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

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

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

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

Also worth reading:

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

Webinars and presentations:

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

Time to upgrade:

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

2. Technical & Musings

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

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

Also worth reading:

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

3. Pick of the Week

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

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

       

1. Spring and Java

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

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

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

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

Also worth reading:

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

Webinars and presentations:

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

Time to upgrade:

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

2. Technical & Musings

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

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

Also worth reading:

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

3. Pick of the Week

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

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

       

Comments

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

 

1. Spring and Java

>> Virtual Threads after JDK 24: What Changed for Production Java [infoq.com]

If you haven’t looked at virtual threads in a while, this is the update you need. Benchmarks, code, and a repo you can run, plus concrete Spring Boot 3 adoption guidance.

Also worth reading:

• >> Idempotent Spring Boot: Safe REST with One Annotation [foojay.io]
• >> Introduction to Spring MockMvc [petrikainulainen.net]
• >> Writing a Thymeleaf component library – part 2 [wimdeblauwe.com]
• >> How to Create a Spring Boot Fraud Scoring Service [foojay.io]
• >> Jakarta Agentic AI Hits Its First Milestone [foojay.io]
• >> Transitioning Java to More Frequent Security Updates [inside.java]
• >> IntelliJ IDEA Goes LSP: Java and Kotlin Intelligence Comes to VS Code, Cursor, and Agentic Flows [jetbrains.com]
• >> Embabel Agent Framework Reaches 1.0 [infoq.com]
• >> The Codename One JavaScript Port Is Now Free and Open Source [foojay.io]
• >> Reflecting on STF support and looking ahead [marcphilipp.de]
• >> Custom ASCII-art startup banners for Quarkus [quarkus.io]

Webinars and presentations:

• >> Under the HAT: Empowering GPU Acceleration for Java [inside.java]
• >> Episode 64 “JIT Compiler From the Ground Up” [AtA] [inside.java]
• >> A Bootiful Podcast: Spring Boot founder and lead Phil Webb [spring.io]
• >> Quarkus Insights #255: Faster, Leaner, Predictable — Quarkus in the Real World [quarkus.io]
• >> WebAssembly on the JVM: Feature Evolution, Performance, and the Transition to Endive [infoq.com]
• >> Automatically Retrofitting JIT Compilers [infoq.com]
• >> The Free-Lunch Guide to Idea Circularity [infoq.com]

Time to upgrade:

• >> Quarkus 3.38.1 and 3.33.3.1 and 3.27.5.1 [quarkus.io]
• >> Jetty 12.1.12 and 12.0.38 [github.com/jetty]
• >> Vert.x 5.1.6 [github.com/eclipse-vertx]
• >> Helidon 4.5.2 [github.com/helidon-io]
• >> Elasticsearch 9.5.0 [github.com/elastic]
• >> Qodana 2026.2: More Security, Better Coverage, Less Configuration [jetbrains.com]
• >> Oracle Java Platform Extension for Visual Studio Code – Version 26.0.1 Is Now Available [inside.java]

2. Technical & Musings

>> The Economic Benefit of Refactoring [martinfowler.com]

We have always known that clean code pays for itself; here is someone putting a number on it in the agentic era. Giles Edwards-Alexander took a bloated 17,155-line data-access layer, refactored it systematically, and then measured what a representative feature change cost an AI agent before and after: input tokens dropped from 159,564 to 27,360, an 83% cut. Definitely a weekend read.

Also worth reading:

• >> The Conductor Developer [martinfowler.com]
• >> Fixing bugs in Event Sourcing is hard, for real? [event-driven.io]
• >> On building scalable control planes [allthingsdistributed.com]
• >> TimeSeries Tiered Storage Journey: Kafka/Flink Streams to Native Cassandra Cold Reads [netflixtechblog.com]
• >> GenRec: Towards LLM-Native Recommendation at Netflix [netflixtechblog.com]
• >> Credential Brokering Patterns for AI Agents Part 2: Protecting the Token Vault with AWS KMS [christianposta.com]
• >> Confidence Techniques for Guiding AI Migration [scottlogic.com]
• >> GitHub agentic workflows and Renovate [frankel.ch]
• >> Use Task Runners for Common Coding Tasks [hamvocke.com]
• >> Modeling Device Capabilities for Analytics [netflixtechblog.com]
• >> Four pillars of agentic AI success [scottlogic.com]

3. Pick of the Week

>> Life is Short [paulgraham.com]

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

       

1. Introduction

The generative AI landscape is evolving rapidly, pushing framework maintainers to rethink how applications connect to diverse large language models (LLMs). With the release of Spring AI, Java developers gained a unified, portable interface to interact with cognitive services.

However, as the ecosystem matured, integrating multiple foundational models within a single runtime classpath introduced configuration conflicts. To solve this, Spring AI introduced major architectural updates. These include the specialized spring-ai-starter-model-google-genai starter module and an explicit model selection paradigm.

In this tutorial, we’ll explore how to integrate Google’s Gemini models into a Spring Boot application using the Gemini Developer API (via Google AI Studio). We’ll walk through a streamlined project setup, dive into text generation patterns using both low-level and high-level APIs, apply prompt templates, enable live web grounding, and stream tokens reactively with WebFlux.

2. Project Setup

To get started, we need a standard Spring Boot 3.x application. Because Spring AI modules are actively updated, it’s highly recommended to manage dependency versions using the Spring AI Bill of Materials (BOM).

2.1. Maven Dependencies

First, let’s configure the Spring AI Starter Google GenAI and Spring AI BOM in our pom.xml file. Since Spring AI artifacts are hosted in the Spring Milestones repository during release cycles, we ensure both the repository and dependency management blocks are properly declared:

<project>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.ai</groupId>
                <artifactId>spring-ai-bom</artifactId>
                <version>2.0.0</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-starter-model-google-genai</artifactId>
        </dependency>
    </dependencies>
</project>

2.2. Activating the Chat Provider via spring.ai.model.chat

In the latest versions of Spring AI, dropping a starter module onto the classpath no longer automatically activates it. This prevents runtime configuration conflicts when your application references multiple LLM providers.

We must explicitly declare our active chat provider inside our application.properties file:

spring.ai.model.chat=google-genai
spring.ai.google.genai.chat.model=gemini-2.5-flash
spring.ai.google.genai.api-key=${SPRING_AI_GOOGLE_GENAI_API_KEY}

Obtain an API key from the Google AI Studio. Using this placeholder syntax explicitly documents the application’s external runtime dependency while preventing hardcoded secrets from leaking into our source control repository.

2.3. Environment Setup

We can satisfy the property placeholder defined above without writing any custom Java decryption or binding code. We’ll simply export the credentials directly into our environment. The auto-configuration engine will automatically resolve the placeholder value at startup:

export SPRING_AI_GOOGLE_GENAI_API_KEY="YourActualSecureGoogleAIStudioKeyHere"

Once this environment variable is set, Spring Boot seamlessly bridges the variable to the properties file placeholder, making the GoogleGenAiChatModel ready for injection.

3. Core Text and Content Generation Strategies

Spring AI gives us two primary abstraction layers for communicating with Gemini models: the foundational ChatModel bean and the highly configurable, fluent ChatClient API. We isolate our interaction logic into a dedicated service layer to follow enterprise design patterns and keep code clean. Then, we expose these capabilities through standard Spring REST controllers.

3.1. Injecting and Using GoogleGenAiChatModel

The GoogleGenAiChatModel represents the foundational, low-level client abstraction. It handles request serialization, HTTP execution against Google’s RPC endpoints, and raw response parsing.

Let’s look at our ChatService, where we inject this bean along with a ChatClient.Builder to initialize our operational layers:

@Service
public class ChatService {
    private final GoogleGenAiChatModel chatModel;
    private final ChatClient defaultChatClient;
    private final ChatClient fluentChatClient;
    public ChatService(GoogleGenAiChatModel chatModel, ChatClient.Builder chatClientBuilder) {
        this.chatModel = chatModel;
        this.defaultChatClient = chatClientBuilder.build();
        this.fluentChatClient = chatClientBuilder
          .defaultSystem("You are a concise technical writer summarizing software concepts.")
          .build();
    }
    public String simplifiedPrompt(String message) {
        return chatModel.call(message);
    }
}

When we invoke chatModel.call(message), the framework packages the raw string into a default prompt context. It then sends this to the configured model variant, extracts the text block from the response payload, and returns it. We expose this in our ChatController:

@RestController
public class ChatController {
    private final ChatService chatService;
    public ChatController(ChatService chatService) {
        this.chatService = chatService;
    }
    @GetMapping("/v1/chat/simple")
    public String simplifiedPrompt(@RequestParam(defaultValue = "Hello") String message) {
        return chatService.simplifiedPrompt(message);
    }
}

This establishes a simple string-in, string-out endpoint. It uses the lowest-level model client abstraction available to verify basic connectivity with the Gemini engine.

3.2. Constructing Prompts With the Fluent ChatClient API

While working directly with the model handles quick operations, production architectures favor the fluent ChatClient API. The ChatClient acts as a facade layer that simplifies prompt assembly and attaches default configuration baselines.

As shown in our service constructor, we pre-configured a specialized fluentChatClient with system instructions. Let’s add the corresponding execution method to ChatService:

public String fluentPrompt(String prompt) {
    return this.fluentChatClient.prompt()
      .user(prompt)
      .call()
      .content();
}

By routing requests through this pre-configured instance, every user query automatically appends the target system instructions before execution. We expose this endpoint in the controller:

@GetMapping("/v1/chat/fluent")
public String fluentPrompt(@RequestParam String prompt) {
    return chatService.fluentPrompt(prompt);
}

This allows us to encapsulate recurring personas or systemic behavior directly within the client wrapper instance. As a result, we don’t need to modify individual incoming text arguments manually.

3.3. Handling Dynamic Inputs via Prompt Templates

Hardcoding parameter logic directly inside strings leads to messy string concatenation and fragile codebases. Spring AI solves this with structured prompt templates, separating instructions from user variables.

Let’s implement a code review capability inside our ChatService using a multiline text block placeholder layout:

public String reviewCode(String language, String codeSnippet) {
    String template = """
            Analyze the following {language} code snippet for memory leaks or inefficiencies.
            Provide an optimized version.
            Code:
            {code}
            """;
    return this.defaultChatClient.prompt()
      .user(u -> u.text(template).params(Map.of("language", language, "code", codeSnippet)))
      .call()
      .content();
}

The client replaces the target tags ({language}, {code}) at runtime, formatting the text cleanly before submission. We expose this via a POST request wrapper in our controller:

@PostMapping("/v1/chat/review")
public String reviewCode(@RequestParam(defaultValue = "Java") String language, @RequestBody String codeSnippet) {
    return chatService.reviewCode(language, codeSnippet);
}

This pattern cleanly decouples structural prompt engineering boundaries from volatile business data, producing a highly reusable, parameter-driven invocation pattern.

3.4. Grounding Responses With Live Google Search Retrieval

LLMs naturally suffer from training cut-off windows and knowledge gaps regarding live, real-world developments. The Google GenAI module exposes an explicit grounding property to seamlessly connect our model with live Google Search indexing.

To activate live search grounding across our entire application, we need to toggle the grounding flag to true inside our configuration properties:

spring.ai.google.genai.chat.google-search-retrieval=true

When this property is enabled, queries regarding current events or breaking news are automatically grounded using fresh search results. Let’s write an endpoint to handle real-time informational requests:

public String searchGroundedPrompt(String currentEventQuery) {
    return this.defaultChatClient.prompt()
      .user(currentEventQuery)
      .call()
      .content();
}

We map this method to our HTTP layer inside our controller configuration:

@GetMapping("/v1/chat/grounded")
public String searchGroundedPrompt(@RequestParam String currentEventQuery) {
    return chatService.searchGroundedPrompt(currentEventQuery);
}

If we pass a request like “Who won the most recent football tournament match yesterday?”, the model uses live Google Search indexing to anchor its response in verified facts, drastically reducing hallucinations. This configuration bridges the gap between static training cutoffs and live, real-world events.

3.5. Processing Real-Time Streaming Responses With Flux

For user-facing interfaces, waiting for a long text block to fully generate on the server results in noticeable latency. Instead, we can stream chunks back to the user, token by token, using Spring Boot’s WebFlux integration.

Let’s add a streaming method to our ChatService that returns a reactive Flux<String> structure:

public Flux<String> streamChatTokens(String prompt) {
    return this.defaultChatClient.prompt()
      .user(prompt)
      .stream()
      .content();
}

We’ll create a specialized StreamingChatController to deliver these tokens cleanly over an open connection pipeline. This controller explicitly produces a text/event-stream media response:

@RestController
public class StreamingChatController {
    private final ChatService chatService;
    public StreamingChatController(ChatService chatService) {
        this.chatService = chatService;
    }
    @GetMapping(value = "/v1/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> streamChatTokens(@RequestParam String prompt) {
        return chatService.streamChatTokens(prompt);
    }
}

When hitting this endpoint, consumers read token data reactively.  This establishes a non-blocking execution pipeline that builds an interactive, low-latency UI flow chunk by chunk.

4. Testing

Testing applications that rely on external generative AI endpoints requires a clear separation of concerns. Running tests shouldn’t trigger external network calls, hit rate limits, or exhaust API quotas during local compilation. To prevent this, we isolate our HTTP layer using Spring Boot’s slice testing along with @MockitoBean.

4.1. Unit Testing via WebLayer MockMvc Mocking

Since our implementation encapsulates all LLM communications within ChatService, we can completely mock this business component. This permits us to cleanly assert controller routing, request parameters, response body expectations, and stream-handling patterns.

Let’s write an isolated test using MockMvc to verify all text-based, template-driven, and reactive stream endpoints without triggering an actual network handshake. First, we set up our simple prompt test to verify basic GET parameter routing and raw response mapping:

@SpringBootTest(properties = {
    "spring.ai.model.chat=google-genai",
    "spring.ai.google.genai.chat.model=gemini-2.5-flash",
    "spring.ai.google.genai.api-key=test-key"
})
@AutoConfigureMockMvc
class ChatControllerUnitTest {
    @Autowired
    private MockMvc mockMvc;
    @MockBean
    private ChatService chatService;
    @Test
    void whenSimpleEndpointIsInvoked_thenReturnsMockedModelResponse() throws Exception {
        when(chatService.simplifiedPrompt(anyString())).thenReturn("Mocked Gemini Response");
        mockMvc.perform(get("/v1/chat/simple").param("message", "Hello"))
          .andExpect(status().isOk())
          .andExpect(content().string("Mocked Gemini Response"));
        verify(chatService).simplifiedPrompt("Hello");
    }
}

Next, we confirm that our fluent prompt endpoint forwards query parameters accurately to the underlying service. Then it returns the configured system-prompt-backed response:

@Test
void whenFluentEndpointIsInvoked_thenReturnsModelContent() throws Exception {
    when(chatService.fluentPrompt(anyString())).thenReturn("Fluent Response");
    mockMvc.perform(get("/v1/chat/fluent").param("prompt", "Explain DI"))
      .andExpect(status().isOk())
      .andExpect(content().string("Fluent Response"));
    verify(chatService).fluentPrompt("Explain DI");
}

For our template-driven endpoint, we validate that the controller correctly processes a multipart payload consisting of query parameters and a text/plain request body:

@Test
void whenReviewEndpointIsInvoked_thenReturnsModelContent() throws Exception {
    when(chatService.reviewCode(anyString(), anyString())).thenReturn("Optimized Code");
    mockMvc.perform(post("/v1/chat/review")
        .param("language", "Java")
        .contentType(MediaType.TEXT_PLAIN)
        .content("class A { }"))
      .andExpect(status().isOk())
      .andExpect(content().string("Optimized Code"));
    verify(chatService).reviewCode("Java", "class A { }");
}

We’ll now verify that search-grounded queries pass their parameters cleanly through the controller layer without parameter binding errors:

@Test
void whenGroundedEndpointIsInvoked_thenReturnsModelContent() throws Exception {
    when(chatService.searchGroundedPrompt(anyString())).thenReturn("Grounded Response");
    mockMvc.perform(get("/v1/chat/grounded").param("currentEventQuery", "latest match winner"))
      .andExpect(status().isOk())
      .andExpect(content().string("Grounded Response"));
    verify(chatService).searchGroundedPrompt("latest match winner");
}

Finally, we test our reactive endpoint to ensure Spring MVC properly negotiates the text/event-stream media type. It will also format the reactive Flux elements into standard Server-Sent Event (data:) frames:

@Test
void whenStreamEndpointIsInvoked_thenReturnsEventStreamContent() throws Exception {
    when(chatService.streamChatTokens(anyString()))
      .thenReturn(reactor.core.publisher.Flux.just("token-1", "token-2"));
    mockMvc.perform(get("/v1/chat/stream").param("prompt", "Stream tokens"))
      .andExpect(status().isOk())
      .andExpect(content().contentTypeCompatibleWith(MediaType.TEXT_EVENT_STREAM))
      .andExpect(content().string("data:token-1\n\ndata:token-2\n\n"));
    
    verify(chatService).streamChatTokens("Stream tokens");
}

By leveraging the modern @MockBean annotation, we inject our mock definitions directly into the application context wrapper, replacing the real bean configuration. This allows us to stub out standard synchronous operations as well as complex reactive Flux stream responses safely and reliably without network overhead.

5. Conclusion

In this tutorial, we configured a Spring Boot application using Spring AI’s updated spring-ai-starter-model-google-genai engine to interact directly with Google AI Studio.

We saw how explicitly defining spring.ai.model.chat=google-genai resolves modern multi-model classpath dependencies. From there, we established a clean architecture using a dedicated ChatService. We built out flexible prompt workflows with the fluent ChatClient API and isolated dynamic parameters using templates. Finally, we enabled live web grounding and streamed responsive outputs via WebFlux Flux.

As always, the complete code samples used in this article are available over on GitHub.

The post Introduction to Google GenAI Chat and Spring AI first appeared on Baeldung.

       

1. Overview

As AI agents become more capable, long-term memory has become just as important as reasoning. While mechanisms such as ChatMemory and Retrieval Augmented Generation (RAG) handle conversations and external knowledge, they don’t answer a different question: What should an agent permanently remember about a user or project?

Spring AI AutoMemoryTools addresses this by enabling agents to persist and recall long-term memories, such as user preferences and project-specific knowledge.

In this article, we’ll explore AutoMemoryTools, its architecture and components, and build a simple Spring Boot chatbot that demonstrates how it works.

2. Dependencies

Let’s start by defining the minimum dependencies possible for demonstrating the Spring AI AutoMemoryTools. We’ll need the spring-ai-starter-model-openai and spring-ai-agent-utils. The first is the starter for integrating any OpenAI-compatible API with Spring AI, and the latter contains the tools we’re exploring in this article. We can use the (current) latest versions:

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-openai</artifactId>
    <version>2.0.0</version>
</dependency>
<dependency>
    <groupId>org.springaicommunity</groupId>
    <artifactId>spring-ai-agent-utils</artifactId>
    <version>0.10.0</version>
</dependency>

3. Spring AI AutoMemoryTools

Spring AI AutoMemoryTools is a Spring AI Community library that implements long-term memory for AI agents. It uses tool calling and file-based persistence. It’s part of the Spring AI Agent Utils, similar to Agent Skills. It’s worth mentioning that it’s inspired heavily by Claude Code and saves developers from implementing common agent capabilities themselves.

Similar to MessageChatMemoryAdvisor (for conversation memory), Spring AI AutoMemoryTools also implements BaseChatMemoryAdvisor. This means it’s related to conversational memory, but it does not focus on the conversation part. Rather, aims to store information about concepts like user preferences, projects, feedback, and more.

3.1. Types of Memory

Let’s look at the types of memory the Spring AI AutoMemoryTools targets:

• User: Remembers who the user is and how to assist them best
• Feedback: Remembers how the user prefers the AI to behave
• Project: Remembers important project context and decisions
• Reference: Remembers where to find information in external systems.

As we’ll see later, these are best described in the AUTO_MEMORY_TOOLS_SYSTEM_PROMPT.md, which is part of the dependency resources. Another thing we’ll see is how we can override this PromptSystemSpec with a custom one. This would mean that these types of memory might no longer exist, unless we define them.

3.2. The Tools

Now, let’s go through the six distinct tools of AutoMemoryTools:

• MemoryView: Reads the contents of a memory file or lists the available memory files in a directory
• MemoryCreate: Creates a new memory file to persist long-term information
• MemoryStrReplace: Updates an existing memory by replacing an exact piece of text
• MemoryInsert: Inserts new content at a specific location within an existing memory file
• MemoryDelete: Removes a memory file or directory from persistent storage
• MemoryRename: Renames or relocates a memory file while preserving its contents.

3.3. Memory System Prompt

As we saw before, the AUTO_MEMORY_TOOLS_SYSTEM_PROMPT.md is part of the library. The library offers two different levels of abstraction. The first is sandboxed, a restricted environment that limits the agent’s access, using the Spring AI AutoMemoryTools. The other is the unrestricted use of FileSystemTools or ShellTools.

In practise, AutoMemoryTools is a specialized abstraction built on top of generic filesystem operations. The Agent can access and manage memory files within the designated memory directories like memory/user, memory/feedback, etc. But it should not have the privileges to do anything outside the memory directory. On the contrary, FileSystemTools and ShellTools are unrestricted unless the developer properly handles this matter.

3.4. How it Works – Bringing All Together

Now that we’ve covered the components, let’s see how a request flows through Spring AI AutoMemoryTools.

When a user sends a request, the LLM combines the Memory System Prompt with the user’s message to determine whether it should read from or write to memory. If needed, it invokes the AutoMemoryTools to manage Markdown files in the configured memory directory, as described by the default AUTO_MEMORY_TOOLS_SYSTEM_PROMPT.md.

After generating the response, the LLM may perform additional memory operations, such as invoking more tools or consolidating existing memory entries. Finally, it returns the response to the user.

4. Spring AI AutoMemoryTools Application

Bringing all together, let’s see this in action. We’ll see three scenarios of configuring a ChatClient to use the Spring AI AutoMemoryTools:

• All-defaults AutoMemoryToolsAdvisor (sandbox operation)
• Manual setup of AutoMemoryToolsAdvisor (sandbox operation)
• FileSystemTools and ShellTools (not sandboxed by default)

4.1. Default AutoMemoryToolsAdvisor Configuration

For the first scenario, we create an AutoMemoryToolsAdvisor with the default, minimum configuration needed:

@Configuration
class ChatClientConfiguration {
    @Value("${agent.memory.dir}")
    String memoryDirectory;
    ChatClient chatClient(ChatModel chatModel) {
        return ChatClient
          .builder(chatModel)
          .defaultAdvisors(
            AutoMemoryToolsAdvisor.builder()
              .memoriesRootDirectory(memoryDirectory)
              .build(),
            MessageChatMemoryAdvisor.builder(
              MessageWindowChatMemory.builder()
                .maxMessages(100)
                .build())
            .build(),
            ToolCallingAdvisor.builder()
              .disableInternalConversationHistory()
              .build())
          .build();
    }
}

This setup uses the default AUTO_MEMORY_TOOLS_SYSTEM_PROMPT.md and defines the memory types we explained earlier. We use the Advisor to intercept all message exchanges. The memoriesRootDirectory() method sets the memory directory, which is also the boundary of access for the Agent. Last, the MessageChatMemoryAdvisor is the known Advisor that handles the memory for the conversation aspect. We set a random value of 100 messages history.

4.2. Custom AutoMemoryTools Configuration

If we still want the sandboxed AutoMemoryTools but we have more system prompts to include, we can use a more custom approach:

@Configuration
class ChatClientConfiguration {
    // ...
    @Value("classpath:/prompts/AUTO_MEMORY_TOOLS_SYSTEM_PROMPT.md")
    Resource memorySystemPromptAutoMemoryTools;
    // ....
    @Bean
    ChatClient chatClientWithMoreSystemPrompt(ChatModel chatModel) {
        return ChatClient
          .builder(chatModel)
          .defaultSystem(p -> p
            .text(memorySystemPromptAutoMemoryTools)
            .param("MEMORIES_ROOT_DIERCTORY", memoryDirectory))
          .defaultTools(
            AutoMemoryTools.builder()
              .memoriesDir(memoryDirectory)
              .build(),
            TodoWriteTool.builder()
              .build())
          .defaultAdvisors(ToolCallingAdvisor.builder()
              .build())
          .build();
    }
}

Here, we do a similar setup as before, but we use the Tools instead. This way we can define the custom PromptSystemSpec, with the prompt in the .md file we provide. However, this prompt is the essence of AutoMemoryTools, where we should define memory types, how to store, and more. So, if we need to override it, better copy the default prompt and append the extra system prompts.

We should note that ChatMemory is not set here, but the TodoWriteTool is used. This has nothing to do with Spring AI AutoMemoryTools. It’s to show that we can have or not have more tools and advisors, depending on the Agent’s needs.

4.3. FileSystemTools and ShellTools

Last, we can have an unrestricted scenario, using FileSystemTools and ShellTools. For example, if the agent already has FileSystemTools or ShellTools for other tasks, there’s no need for AutoMemoryTools:

@Configuration
class ChatClientConfiguration {
    // ...
    @Value("classpath:/prompts/AUTO_MEMORY_FILESYSTEM_TOOLS_SYSTEM_PROMPT.md")
    Resource memorySystemPromptFilesystemTools;
    // ....
    @Bean
    ChatClient chatClientWithoutAutoMemoryTools(ChatModel chatModel) {
      return ChatClient
        .builder(chatModel)
        .defaultSystem(p -> p
          .text(memorySystemPromptFilesystemTools)
          .param("MEMORIES_ROOT_DIERCTORY", memoryDirectory))   // tells the agent where to write
          .defaultTools(
            ShellTools.builder()
              .build(),         // Bash — mkdir, ls, etc.
            FileSystemTools.builder()
              .build())    // Read, Write, Edit — memory file operations
          .defaultAdvisors(ToolCallingAdvisor.builder()
              .build())
        .build();
    }
}

The file AUTO_MEMORY_FILESYSTEM_TOOLS_SYSTEM_PROMPT.md can also be found in the library. For the demonstration, we can copy it over. Using this one, the same memory conventions apply: .md files, two-step save, etc. But the agent conventionally has full filesystem access and stays in the configured directory only.

The two tools are the ones the Agent needs to do all the file creation, removal, editing, etc, to keep the memory in the file system.

4.4. Other Project Files

For the demonstration, we’ll use spring-web-mvc, with a RestController:

@PostMapping("/chat-with-memory")
ResponseEntity<String> chat(@RequestBody String question, @RequestHeader("X-Conversation-ID") String conversationId) {
    String answer = chatClient
      .prompt()
      .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, conversationId))
      .user(question)
      .call()
      .content();
    return ResponseEntity.ok(answer);
}

As mentioned earlier, the conversationId is needed, since Spring AI AutoMemoryTools implements BaseChatMemoryAdvisor.

Let’s run the application using a local Ollama Qwen model:

First, we ask the Agent to save some info. Then we request this info, but notice the different conversationId! The Agent doesn’t know anything about session-1. Asking as session-2 again, the Agent remembers it.

Depending on our machine, the Agent interaction with the file system might be quite slow. We can also see the directories that the Agent created, along with the file content:

5. Conclusion

In this article, we went through Spring AI AutoMemoryTools. We covered the use cases and the basic definitions. Then we walked through the six operations and the three options to use them. Finally, we used Spring AI to demonstrate it in practise.

As always, the source code of the examples can be found over on GitHub.

The post Spring AI AutoMemoryTools first appeared on Baeldung.

       

1. Overview

We’re increasingly building AI agents that can handle a user’s entire request on their own. Instead of simply answering questions from what a Large Language Model (LLM) already knows, these agents reason through a problem, break it down into steps, call external tools, and even execute local scripts.

As these requests grow in complexity, packing every capability into a single agent becomes unmanageable. The natural fix is to create smaller agents, each specialized in one job. However, getting these agents to talk to each other is a challenge in itself, as they run as independent services built using different languages, frameworks, and LLMs.

The Agent2Agent (A2A) Protocol addresses this issue by defining a standard for agents to discover each other and communicate.

In this tutorial, we’ll practically explore the A2A protocol by implementing its client and server architecture using Spring AI.

2. Agent2Agent (A2A) Protocol 101

Before we dive into the implementation, let’s take a closer look at the protocol and the way two agents interact:

An agent acting as a server exposes its capabilities to the outside world, while an agent acting as a client consumes them.

Discovery happens through an Agent Card, which is a JSON document that a server publishes at a well-known URL. This card exposes the agent’s details, including the list of skills it offers. A client agent fetches this card first to learn what a remote agent can do and where to reach it.

The client sends a Message that describes the work to be done in plain natural language. The remote agent turns that message into a Task, processes it, and returns one or more Artifacts that carry the actual response content.

A2A is a complex and vast topic. We can refer to the official specification to learn more.

3. The Project We’re Building

To see the protocol in action, we’ll build a job screening system for recruiters:

As we can see, our system is made up of one orchestrator agent that acts as the A2A client and communicates with three specialized remote agents that act as A2A servers.

A recruiter submits a candidate’s details to a single REST endpoint. Behind the scenes, the orchestrator agent will break the request down and delegate each task to a specialized agent. Once every agent responds, the orchestrator will merge the individual verdicts into one short screening summary.

4. Creating an A2A Server

Since creating A2A servers follows the exact same structure, we’ll only walk through implementing the skills matcher agent.

The remaining two remote servers differ solely in their tools and prompts. To view the complete implementation of the project, we can refer to the repository backing this tutorial.

4.1. Dependencies and LLM Configuration

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

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-openai</artifactId>
    <version>2.0.0</version>
</dependency>
<dependency>
    <groupId>org.springaicommunity</groupId>
    <artifactId>spring-ai-a2a-server-autoconfigure</artifactId>
    <version>0.3.0</version>
</dependency>

Here, we first import Spring AI’s OpenAI starter dependency, which we’ll use to interact with an LLM. Additionally, we import the A2A server autoconfigure dependency from the Spring AI community, which takes care of serving our agent card at startup and handling A2A requests.

Next, let’s configure our OpenAI API key and chat model in the application.yaml file:

spring:
  ai:
    openai:
      api-key: ${OPENAI_API_KEY}
      chat:
        model: gpt-5.5

Here, we specify OpenAI’s GPT 5.5 model using the gpt-5.5 model ID. Alternatively, we can use a different chat model, as the specific AI model or provider is irrelevant for this demonstration.

With these two properties set, Spring AI automatically creates a bean of type ChatClient.Builder, which we’ll use in the upcoming section.

4.2. Creating a Tool and Registering It With ChatClient

Next, let’s configure the actual capability that our A2A server offers. We’ll create a SkillsMatcherTools class and define a tool that evaluates a candidate’s skills:

@Tool(
  name = "match-skills",
  description = "Compares a candidate's skills against a job's required skills and returns a fit score"
)
SkillsMatchResult matchSkills(
  @ToolParam(description = "Candidate skills, comma-separated") String candidateSkills,
  @ToolParam(description = "Required job skills, comma-separated") String requiredSkills
) {
    // ... rudimentary implementation
}
record SkillsMatchResult(
    int score,
    Verdict verdict,
    Set<String> matchedSkills,
    Set<String> missingSkills
) {}
enum Verdict {
    STRONG_MATCH,
    PARTIAL_MATCH,
    WEAK_MATCH
}

We annotate our method with the @Tool annotation and give it an explicit name along with a short description. Both of these values help the AI model decide if and when to invoke this tool. Similarly, we describe both method parameters with the @ToolParam annotation so that the LLM knows the format we expect the inputs to be in.

We’ve deliberately omitted the method implementation here, since it’s not important to our A2A understanding.

Next, let’s create a ChatClient bean and register our tool with it:

@Bean
ChatClient chatClient(
  ChatClient.Builder chatClientBuilder,
  SkillsMatcherTools skillsMatcherTools
) {
    return chatClientBuilder
      .defaultSystem("""
        You are a skills-matching assistant for recruiters.
        Use the match-skills tool to compare a candidate's skills
        against a job's required skills, then summarize the result.
        """)
      .defaultTools(skillsMatcherTools)
      .build();
}

Here, we use the ChatClient.Builder bean that Spring AI configures for us, along with the SkillsMatcherTools bean we defined above, to create a ChatClient bean. This class acts as our main entry point for interacting with the configured LLM.

Additionally, we define a system prompt defining the agent’s role, and then register our tool class using the defaultTools() method. This enables the model to call our tool method when it receives a matching request.

4.3. Defining an AgentExecutor to Handle A2A Requests

The ChatClient bean we’ve defined can only be used by components within our own application. To let other agents send us tasks, we need to define an AgentExecutor bean that handles incoming A2A requests:

@Bean
AgentExecutor agentExecutor(ChatClient chatClient) {
    return new DefaultAgentExecutor(chatClient, (client, requestContext) -> {
        String userMessage = DefaultAgentExecutor.extractTextFromMessage(requestContext.getMessage());
        return client
          .prompt()
          .user(userMessage)
          .call()
          .content();
    });
}

Here, we use the DefaultAgentExecutor class, passing it our ChatClient bean along with a handler function that defines how we want to respond. In the handler function, we extract the plain text of the incoming message and pass it to our LLM as a user prompt. The response from our chatClient bean is automatically wrapped into an artifact and sent back to the calling agent.

4.4. Describing Our Agent Using an AgentCard

Finally, we need to expose an Agent Card that accurately describes our agent:

@Bean
AgentCard agentCard(
  @Value("${server.host}") String host,
  @Value("${server.port}") int port
) {
    return new AgentCard.Builder()
      .name("Skills Matcher Agent")
      .description("Evaluates how well a candidate's skills match a job's required skills")
      .url(String.format("http://%s:%d/", host, port))
      .version("1.0.0")
      .capabilities(new AgentCapabilities
        .Builder()
        .streaming(false)
        .build())
      .defaultInputModes(List.of("text"))
      .defaultOutputModes(List.of("text"))
      .skills(List.of(new AgentSkill.Builder()
        .id("skills_matching")
        .name("Skills Matching")
        .description("Compares candidate skills to job requirements and scores the fit")
        .tags(List.of("hiring", "recruiting"))
        .build()))
      .protocolVersion("1.0.1")
      .build();
}

Here, we create an AgentCard bean and define the important properties of name, description, and skills. Client agents rely on these properties to decide whether a remote agent and the capabilities it offers are a good fit for a given task.

Similarly, we define the url property from the host and port of our running application, telling clients where to reach us. Additionally, we declare that our agent doesn’t support streaming and it exchanges plain text in both directions.

It’s worth noting that every property we set above is mandatory, and the builder rejects a card with any of them missing. With this bean defined, the auto-configuration serves our agent card at the .well-known/agent-card.json path.

5. Creating an A2A Client

With our specialized agents ready, we’ll build our A2A client, i.e., the job screening orchestrator that delegates the actual evaluation to them.

5.1. Dependencies

Our orchestrator is a separate application that also talks with an LLM. For this reason, we’ll need to import a chat model dependency and configure the API key and model properties, just like we did in our A2A server.

In addition to that, we need to add the A2A Java SDK to our pom.xml:

<dependency>
    <groupId>io.github.a2asdk</groupId>
    <artifactId>a2a-java-sdk-client</artifactId>
    <version>0.3.3.Final</version>
</dependency>

This SDK provides us the classes we need to fetch agent cards, open connections to remote agents, and send them messages.

We should note that we didn’t explicitly declare this dependency while building our A2A server, as the server autoconfigure dependency brings it in transitively. However, for an agent purely acting as a client, we’ll need to add this ourselves.

5.2. Discovering Remote Agents at Startup

Our orchestrator can only delegate work to agents it knows about, so let’s list their addresses in the application.yaml:

remote:
  agents:
    urls:
      - http://localhost:8081
      - http://localhost:8082
      - http://localhost:8083

Here, we configure the base URLs of our remote agents using a custom property. We need to make sure to update these values if the agents run on a different host or port.

Next, let’s create an AgentRegistry component that fetches agent cards from these URLs when the application starts:

private final Map<String, AgentCard> agentCards = new HashMap<>();
AgentRegistry(@Value("${remote.agents.urls}") List<String> agentUrls) {
    for (String url : agentUrls) {
        String path = new URI(url).getPath();
        AgentCard card = A2A.getAgentCard(url, path + ".well-known/agent-card.json", null);
        agentCards.put(card.name(), card);
    }
}

Here, we iterate over each configured URL inside the constructor and retrieve its agent card from the .well-known/agent-card.json path. Then, we store the resulting AgentCard instances in an in-memory map keyed by the agent’s name.

To expose the fetched agent cards to other components, let’s add a couple of helper methods to this class:

AgentCard get(String agentName) {
    return agentCards.get(agentName);
}
String describeAgents() {
    return agentCards
      .values()
      .stream()
      .map(card -> "- " + card.name() + ": " + card.description())
      .collect(Collectors.joining("\n"));
}

The get() method returns the card of a specific agent by its name. Meanwhile, the describeAgents() method renders the formatted summary of all available remote agents with their descriptions. We’ll use these helper methods in the upcoming sections to define additional components.

5.3. Communicating With Remote Agents

Our A2A client is now capable of discovering remote agents at startup. Next, let’s create a RemoteAgentClient component that actually communicates with these agents:

String sendMessage(String agentName, String task) {
    AgentCard agentCard = agentRegistry.get(agentName);
    CompletableFuture<String> response = new CompletableFuture<>();
    BiConsumer<ClientEvent, AgentCard> responseConsumer = (event, card) -> {
        TaskEvent taskEvent = (TaskEvent) event;
        response.complete(taskEvent.getTask()
          .getArtifacts()
          .stream()
          .map(Artifact::parts)
          .map(this::extractText)
          .collect(Collectors.joining("\n")));
    };
    Client client = Client.builder(agentCard)
      .clientConfig(new ClientConfig.Builder()
        .setAcceptedOutputModes(List.of("text"))
        .build())
      .withTransport(JSONRPCTransport.class, new JSONRPCTransportConfig())
      .addConsumers(List.of(responseConsumer))
      .streamingErrorHandler(response::completeExceptionally)
      .build();
    Message message = A2A.toUserMessage(task);
    client.sendMessage(message);
    return response.get(60, TimeUnit.SECONDS);
}
private String extractText(List<Part<?>> parts) {
    return parts
      .stream()
      .filter(TextPart.class::isInstance)
      .map(TextPart.class::cast)
      .map(TextPart::getText)
      .collect(Collectors.joining("\n"));
}

Here, we start by fetching the target agent’s card from our registry, as the SDK uses it to build a client.

Since the SDK returns responses asynchronously, we register a consumer that receives the completed task. Then, it pulls the text out of its artifacts, and passes it to our CompletableFuture response. Then, we convert the given task into an A2A message, send it to the remote agent, and wait for the response to complete.

Next, let’s expose this capability as a tool that our orchestrator’s LLM can call:

@Tool(
  name = "send-message-to-agent",
  description = "Sends a task to a remote agent and returns its response."
)
String sendMessageToAgent(
  @ToolParam(description = "Name of the remote agent") String agentName,
  @ToolParam(description = "The task to perform") String task
) {
    return remoteAgentClient.sendMessage(agentName, task);
}

This single tool is all the orchestrator needs to reach all our configured agents. The LLM will decide which agent to contact and what to ask it, simply by filling in the agentName and task parameters.

5.4. Building the Orchestrator ChatClient

With our discovery and communication logic in place, let’s create the ChatClient bean for our orchestrator agent:

@Bean
ChatClient chatClient(
  ChatClient.Builder chatClientBuilder,
  AgentRegistry agentRegistry,
  RemoteAgentTools remoteAgentTools
) {
    return chatClientBuilder
      .defaultSystem("""
        You are a job-screening orchestrator for recruiters.
        You do not evaluate candidates yourself. Instead, you delegate
        to the following remote agents:
        %s
        Once all agents have responded, combine their responses into a short screening summary.
        """.formatted(agentRegistry.describeAgents()))
      .defaultTools(remoteAgentTools)
      .build();
}

In our system prompt, we explicitly instruct the model not to evaluate candidates on its own. Instead, we inject the list of discovered agents using the describeAgents() method and ask it to delegate the individual evaluations to them.

Then, we register our tool, which gives the model the capability to actually reach these agents.

5.5. Exposing a REST API

Finally, let’s use the orchestrator ChatClient we’ve defined and expose a REST API endpoint to accept candidate screening requests:

@PostMapping("/screenings")
ScreeningResponse screenCandidate(@RequestBody ScreeningRequest screeningRequest) {
    String verdict = chatClient
      .prompt()
      .user(screeningRequest.toString())
      .call()
      .content();
    return new ScreeningResponse(verdict);
}
record ScreeningRequest(
  String name,
  String email,
  String jobTitle,
  String requiredSkills,
  String candidateSkills,
  int expectedSalary
) {}
record ScreeningResponse(
  String verdict
) {}

Our endpoint accepts a ScreeningRequest record holding everything our agents need, namely the candidate’s identity, the job details, and the expected salary.

We simply pass the record’s string representation to the model as a user prompt and return the resulting summary as a ScreeningResponse. This way, our orchestrator client receives the full candidate details and distributes the relevant data to each of our specialized agents.

6. Testing Our Implementation

With our architecture implemented, let’s start all our agents and test the job screening flow.

We’ll use the HTTPie CLI to invoke our screening endpoint:

http POST :8080/screenings \
  name="John Doe" \
  email="john.doe@baeldung.com" \
  jobTitle="Backend Developer" \
  requiredSkills="Java, Spring Boot, AWS, Kafka" \
  candidateSkills="Java, Spring Boot, Azure, Kafka" \
  expectedSalary:=110000 \
  | jq -r '.verdict'

Here, we submit sample data for a candidate and pipe the response through jq to print the verdict as readable text.

Let’s see what we get as a response:

Screening summary for John Doe (Backend Developer):
- Salary: Expected salary of $110,000 is within budget.
- Background check: Clear; no relevant flags found.
- Skills match: Strong match, 75% fit. Only missing AWS experience, though Azure experience may be transferable.
Overall: John Doe appears to be a good candidate to proceed with, with follow-up recommended on AWS/cloud experience.

As we can see, the orchestrator delegated the request to all three remote agents and consolidated their individual verdicts into a single summary.

7. Conclusion

In this article, we’ve understood what the Agent2Agent (A2A) protocol is and practically implemented it using Spring AI.

We started by building an A2A server, exposing its capability through an agent card. Next, we built an A2A client that acts as an orchestrator, dynamically discovering remote agents and delegating tasks to them. Finally, we tested the complete flow of our implementation and confirmed that our orchestrator combines the responses of all the specialized agents into one screening summary.

As always, all the code examples used in this article are available over on GitHub.

The post Exploring Agent2Agent Protocol (A2A) With Spring AI first appeared on Baeldung.

       

1. Spring and Java

>> The Self-Building Agent: a LangChain4j Experiment [infoq.com]

A interesting reveral of the typical agent tutorial by pointing an LLM at the LangChain4j documentation and having it design an agent. Meta yes, and worth a quick read.

Also worth reading:

• >> To Cache or Not to Cache Virtual Threads [quarkus.io]
• >> Pairing In-Process and Hosted Embeddings for Java MCP Tool Development [inside.java]
• >> New Between-Quarters Security Updates for Java: What CSPUs Mean for Your Release Pipeline [foojay.io]
• >> Reverse Engineering with Hibernate 7.4 and IntelliJ IDEA [jetbrains.com]
• >> Writing a Thymeleaf component library [wimdeblauwe.com]
• >> Quality Outreach Heads-up – JDK 28: jlink cacerts plugin [inside.java]
• >> KotlinLLM is Going Open Source [jetbrains.com]
• >> RFC 9880 and the IoT Validation Problem [frankel.ch]
• >> AI Found the Bugs. Who’s Patching Your EOL Java Code? [foojay.io]
• >> Secure Your APIs: OAuth2 and JWT for Beginners [jetbrains.com]

Webinars and presentations:

• >> Episode 63 “AI Solutions with Spring AI 2.0” [I/O] [inside.java]
• >> A Bootiful Podcast: Java Developer Advocate Billy Korando on Java 27 and Beyond [spring.io]
• >> Spring Office Hours Podcast: S5E19 – Docker, Compose, Testcontainers, Oh My! [spring.io]
• >> Clean Architecture for Serverless: Business Logic You Can Take Anywhere [infoq.com]

Time to upgrade:

• >> Quarkus 3.37.4 and 3.33.3 [quarkus.io]
• >> GraalVM Community 25 Innovation 2 [github.com/graalvm]
• >> Zuul 4.1.3 and 4.1.2 [github.com/Netflix]
• >> Micronaut Core 5.0.7 [github.com/micronaut-projects]

2. Technical & Musings

>> The Orchestrator’s Tax [martinfowler.com]

Insight into multi-agent coding setups. Exploratory rather than prescriptive, and better for it.

Also worth reading:

• >> Credential Brokering Patterns for AI Agents Part 1: Don’t Give the Agent the Keys [christianposta.com]
• >> The Rise of Open Weights; And the fall of commercial AI? [scottlogic.com]
• >> Throw, Result, or neither? [event-driven.io]
• >> Codeberg Divides [lucumr.pocoo.org]
• >> Shifting readiness left: What AI can (and can’t) do for organisational readiness [scottlogic.com]

3. Pick of the Week

>> First, ten [seths.blog]

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

       

1. Introduction

When working with Apache Spark, we often encounter situations where a DataFrame becomes empty after applying transformations, filters, or joins.

Before triggering expensive actions or saving data to external storage, it’s a best practice to verify if the DataFrame contains any rows. While this may seem like a trivial check, different approaches trigger different Spark actions and can have a noticeable impact on performance, especially for large datasets.

In this tutorial, we’ll explore different ways to check whether a Spark DataFrame is empty.

2. Setup

First, let’s create the following sample DataFrame:

public static Dataset getDataFrame(SparkSession spark) {
    List<Row> players = List.of(
      RowFactory.create(1, "Messi", "Argentina"),
      RowFactory.create(2, "Ronaldo", "Portugal"),
      RowFactory.create(3, "Mbappe", "France"));
    return spark.createDataFrame(players, PLAYER_SCHEMA);
}

We’ll use this DataFrame throughout the examples.

3. Using the isEmpty() method

Since Spark 2.4.0, the easiest way to check whether a Dataset is empty is by using the isEmpty() method.

Let’s create an empty DataFrame by filtering for a country that doesn’t exist in the dataset.

Dataset<Row> englandPlayers = allPlayers.filter(col("country").equalTo("England"));
Assertions.assertTrue(englandPlayers.isEmpty());

Since there are no England players in the dataframe, the filter returns an empty dataframe and isEmpty() returns true.

4. Using the count() method

Another way to check for emptiness is by counting the number of rows in a DataFrame and checking if it’s zero:

Dataset<Row> englandPlayers = allPlayers.filter(col("country").equalTo("England"));
Assertions.assertEquals(0, englandPlayers.count());

Here, we invoked count() and verified that the number of rows is 0.

5. Using the takeAsList() Method

Another approach is to retrieve at most one row using takeAsList():

Dataset<Row> englandPlayers = allPlayers.filter(col("country").equalTo("England"));
Assertions.assertEquals(0, englandPlayers.takeAsList(1).size());

Here we called the takeAsList(1), which returns at most one row. We can then verify that the returned list is empty by checking whether its size is 0. Since only one row is requested, Spark can stop processing once it finds the first matching row, making this approach more efficient than counting every row.

Alternatively, we can also check if the list is empty instead of size():

Assertions.assertTrue(englandPlayers.takeAsList(1).isEmpty());

6. Comparing Methods for Performance

Although all of these approaches can determine whether a DataFrame is empty, they don’t have the same performance characteristics.The isEmpty() method is the recommended approach because it’s specifically designed for this purpose. Internally, Spark only needs to determine whether at least one row exists, allowing it to stop processing as soon as a row is found.

Similarly, takeAsList(1) requests only a single row. Once Spark retrieves the first row, it can terminate the scan, making this approach much more efficient than counting every row. In contrast, count() computes the total number of rows in the DataFrame. Since Spark must process the entire dataset to produce an exact count, this approach is considerably more expensive for large DataFrames.

In general, we should prefer isEmpty() whenever it’s available. If we’re working with an older Spark version that doesn’t support it, takeAsList(1).isEmpty() is a good alternative. We should reserve count() for situations where we also need the total number of rows.

7. Conclusion

In this article, we explored several ways to determine whether a Spark DataFrame is empty. We started with the isEmpty() method, which is the simplest and most expressive solution, and then looked at alternatives based on count() and takeAsList().

In most situations, isEmpty() is the preferred choice because it’s both expressive and efficient. For older Spark versions, takeAsList(1).isEmpty() provides a practical alternative, while count() is best reserved for cases where the total number of rows is also needed.

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

The post Check if Spark Dataframe Is Empty first appeared on Baeldung.