1. Spring and Java

>> Distributed Cache Invalidation Patterns [foojay.io]

A pragmatic tour through distributed cache invalidation, with concrete Spring Boot + Redis code for each pattern. Good brushup.

Also worth reading:

• >> Eliminating Flaky Tests to End World Hunger [foojay.io]
• >> BoxLang AI Deep Dive — Part 3 of 7: Multi-Agent Orchestration [foojay.io]
• >> Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem [foojay.io]
• >> Which Java Runtime Should You Use in Production? Comparing OpenJDK Distributions [foojay.io]
• >> Redesigning Banking PDF Table Extraction: A Layered Approach with Java [infoq.com]
• >> Google ADK for Java 1.0 Introduces New App and Plugin Architecture [infoq.com]
• >> Building a Personalized Content Delivery System [foojay.io]
• >> How the JVM Optimizes Generic Code [inside.java]
• >> You Must Avoid Final Field Mutation – Inside Java Newscast #110 [nipafx.dev]
• >> Kotlin Professional Certificate by JetBrains – Now on LinkedIn Learning [jetbrains.com]
• >> Introducing Koog Integration for Spring AI [jetbrains.com]

Webinars and presentations:

• >> Episode 56 “Ask the Architects at JavaOne” [AtA] [inside.java]
• >> Episode 55 “You Must Avoid Final Field Mutation” [IJN] [inside.java]
• >> A Bootiful Podcast: Dr. Venkat Subramaniam and James Ward [spring.io]
• >> Spring Office Hours Podcast: S5E13 – Community Potluck [spring.io]
• >> A Bootiful Podcast: the legendary Craig Walls [spring.io]

Time to upgrade:

• >> Azul Zulu April 2026 Quarterly Update Released [foojay.io]
• >> Jakarta Persistence 4.0 Milestone 2 [in.relation.to]
• >> Quality Outreach Heads-up – JDK 27: Obsolete Translation Resources Removed [inside.java]
• >> IntelliJ IDEA 2026.1.1 Is Out! [jetbrains.com]
• >> Quarkus 3.34.6 and 3.34.5 – Maintenance releases [quarkus.io]
• >> Spring Boot 3.5.14, 4.0.6, and 4.1.0-RC1 available now [spring.io]
• >> Spring for Apache Pulsar 1.2.17 and 2.0.5 are now available [spring.io]
• >> Spring for Apache Kafka 4.1.0-RC1, 4.0.5, and 3.3.15 Available [spring.io]
• >> Spring Security 2026.04 Releases – Contains CVE Fixes [spring.io]
• >> Spring Authorization Server 1.5.7 Available Now [spring.io]
• >> Spring Data 2025.1.5 and 2025.0.11 released [spring.io]
• >> Spring Data 2026.0.0-RC1 enters release candidate phase [spring.io]
• >> Spring Framework 6.2.18 and 7.0.7 Available Now [spring.io]
• >> Vert.x 5.0.11 [github.com/eclipse-vertx]
• >> Apache Camel 4.14.6, 4.14.7, 4.18.2, and 4.20.0 [github.com/apache]
• >> Helidon 3.2.17 [github.com/helidon-io]
• >> Payara Platform 7.2026.4 [github.com/payara]

2. Technical & Musings

>> Making illegal state unrepresentable [frankel.ch]

A solid take on the classic make illegal states unrepresentable principle, walking through the idea across several languages. Types are still our first line of defense against bad data.

Also worth reading:

• >> Yoda Principle for better integrations [event-driven.io]
• >> Playing Well With Others: An Example [jbrains.ca]
• >> The invisible engineering behind Lambda’s network [allthingsdistributed.com]
• >> OpenTelemetry glossary: 30 terms you should know [nurkiewicz.com]
• >> The Human Infrastructure: How Netflix Built the Operations Layer Behind Live at Scale [netflixtechblog.com]
• >> Predicting Risk in Content Launches [netflixtechblog.com]

3. Pick of the Week

>> How The Heck Does Shazam Work? [perthirtysix.com]

       

1. Introduction

When working with production applications in Java, we often find ourselves configuring HTTPS, enabling secure outbound communication, or managing trust stores. Keytool is the standard tool for working with the required keys and certificates and thus managing Java keystores.

In this tutorial, we’ll focus on a specific task: importing a p7b certificate file into a Java keystore using keytool.

2. Understanding the P7B (PKCS#7) Format

Before we dive into the steps to import a P7B file, it’s worth reviewing and understanding the PKCS#7 format.

In cryptography, PKCS#7 is a standard syntax for storing cryptographically signed or encrypted data.

One common use for this format is to store SSL certificates. Often, certificate bundles are stored and shared as a .p7b file format.

2.1. Certificate Bundle

When creating self signed certificates for development use, it’s usually sufficient to have a private key and a self-signed certificate containing the public key. However, when working with production applications that are expected to be available over the internet, we typically need our certificates to be validated by a known Certificate Authority (CA).

Browsers validate a site by validating the site’s certificate. Each site presents its own certificate along with information to a chain of intermediate certificates, eventually leading to the root certificate of a CA. Since the browsers trust the CA, any site presenting a validated certificate with a clear chain of certificates leading to a root CA certificate is considered valid.

Once a certificate is validated by a CA, they typically provide a certificate chain consisting of its own root certificate and zero or more intermediate certificates. This certificate chain is provided as a bundle of certificates, sometimes as a .p7b file.

2.2. The P7B Format

A P7B file is a PKCS#7 container that can store one or more certificates. It may be encoded either in the binary DER format or in the Base64 PEM format.

When working with Java servers (such as Tomcat), we need to ensure that all the certificates in the bundle are imported into our keystore to prove the validity of our certificate.

Browsers on all modern devices recognise certificates validated by a CA. During the process of certificate validation, a CA will typically share the signed public certificate for our site along with a certificate chain, aka certificate bundle.

Sometimes, the certificate bundle comes as a file with a .p7b extension. We note that depending on the encoding, the contents may not be easily readable in a plain text editor. Therefore, we need a few tools to work with these certificates and import them into our keystore.

3. Preparing a P7B file

Now that we’ve understood the P7B format, let’s dive into the process.

Before we can import a certificate bundle, we need a file containing the certificate bundle. Since we don’t have a .p7b provided by a CA, we’ll use the public certificate from Baeldung.com.

First, we’ll download the chain and convert it into the P7B file format.

3.1. Downloading the Certificate Bundle

Most modern browsers allow exporting of certificates to PKCS#7 format encoded files. However, we’ll do a full command-line interface version using the openssl command on a Linux terminal:

$ openssl s_client -connect www.baeldung.com:443 -showcerts </dev/null

This command prints out several certificates along with some other information about each certificate. Each certificate can be identified easily because of the beginning and ending markers:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

We can now copy each of those certificates (including the markers) and store them as a separate .pem file. So now we have three files site.pem, intermediate.pem and root.pem.

Now let’s use them to create a .p7b bundle:

$ openssl crl2pkcs7 -nocrl -certfile site.pem -certfile intermediate.pem \
-certfile root.pem -out site-chain.p7b

Finally, we can verify that all certificates of interest are present in the bundle:

$ openssl pkcs7 -print_certs -in site-chain.p7b -noout

We see three certificates printed clearly as expected.

3.2. The Problem Importing P7B file

Now that we have a valid certificate bundle in the .p7b file format, let’s check it with keytool:

$ keytool -printcert -file site-chain.p7b

This command prints information about the three certificates clearly.

Let’s attempt to import this as-is:

$ keytool -importcert -file site-chain.p7b -keystore test-keystore.jks -alias site

The output presents an error:

keytool error: java.lang.Exception: Input not an X.509 certificate

The certificate import fails because the keytool -importcert expects the input file to contain exactly one X.509 PEM or DER encoded certificate.

4. Importing the P7B file

We observe that the direct import of a certificate bundle using keytool can be problematic. The solution is to break down the bundle into its individual certificates and then import those certificates one by one.

4.1. Converting to PEM Encoding

To break the bundle into individual PEM files, first, we’ll convert the bundle from the PKCS #7 to a PEM encoded bundle:

$ openssl pkcs7 -print_certs -in site-chain.p7b -out site-chain.pem

This produces a PEM file containing one or more X.509 certificates:

-----BEGIN CERTIFICATE-----
.......
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
.......
-----END CERTIFICATE-----

We’re now ready to use keytool to import the certificates.

4.2. Importing the PEM Bundle

Now that the file is in a format compatible with the keytool import option, we can perform the input:

$ keytool -importcert -file site-chain.pem -keystore test-keystore.jks -alias site

This command requires us to set a keystore password and asks us if we trust the certificate. Then the output shows success:

Trust this certificate? [no]:  yes
Certificate was added to keystore

This imports the site’s certificate under the alias site.

If we need the intermediate and root certificates as well in the same keystore, then we need to import them individually. From site-chain.pem we can copy each of those certificates (including the begin and end markers) and store them as a separate .pem file. So now we have two more files, intermediate.pem and root.pem.

We can use the same command with different input files and aliases to import the root and intermediate certificates as well:

$ keytool -importcert -file root.pem -keystore test-keystore.jks -alias root
$ keytool -importcert -file intermediate.pem -keystore test-keystore.jks -alias intermediate

4.3. Verifying the Import

Now we have all certificates imported, let’s verify them:

$ keytool -list -v -keystore test-keystore.jks

This command requests the previously set password and then shows us detailed information about all the imported certificates. At the beginning of the output, we see:

Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 3 entries

That’s it. Our keystore is now ready to use.

5. Conclusion

In this article, we explored how keytool works with certificate bundles in the PKCS#7 (.p7b) format. While these files can contain complete certificate chains, they’re not always directly supported for import.

We learnt that keytool expects X.509 certificates in DER or PEM format, not container formats like PKCS#7. Converting the .p7b bundle into individual certificates ensures a successful and predictable import process.

       

1. Overview

In the last few years, there has been a lot of effort in the Java ecosystem to improve JVM performance. We have seen the JIT compiler, then the Ahead of Time (AoT) Compilation, and lately the Native Images.

Popular Java frameworks, like Micronaut and Spring, have moved in the same direction to achieve better performance through compilation improvements. Spring offers both Ahead of Time and Native Image support. However, in such big frameworks, there is still a lot of use of Reflection, so there is still plenty of room for improvement. The latest feature, to be introduced in Spring Boot 4, is an AOT optimization for Spring Data, with the AOT Repositories.

In this article, we’re going to see what the new feature of Spring Data AOT Repositories brings in. We’re going to use one of the milestone versions, since this new feature is not offered in any release version yet. Then, we’ll demonstrate how it works. In the end, we’re going to compare its usage with the current alternatives, using Spring Boot 3 with and without AOT compilation.

2. Dependencies

Let’s start by defining the minimum dependencies possible, for demonstrating the Spring Data AOT Repositories. We can only keep the spring-boot-starter-web and spring-boot-starter-data-jpa. The first is for offering an endpoint to verify that the repository actually works, and the latter contains everything needed for Spring to interact with a database:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>4.0.5</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
    <version>4.0.5</version>
</dependency>

Spring Boot major version 4 is only available in early stages. We’re still going to use the stable 4.0.5 for our demonstration.

3. Spring Data Repository

Moving on, let’s look at how repository implementations have evolved from being runtime proxies to the build-time generated code with Spring Data AOT Repositories. We’ll use a very simple and popular example of a User entity and the respective UserRepository. This will let us compare behavior and performance across the three options of repositories without AOT, repositories with AOT (but before AOT Repositories), and AOT Repositories.

3.1. The Domain Model

We’ll use a short User entity, with just three fields, for demonstration purposes:

@Entity
@Table(name = "USERS")
public class User {
    @Id
    @GeneratedValue
    private Long id;
    @Column(name = "first_name")
    private String firstName;
    @Column(name = "last_name")
    private String lastName;
    // constructors, setters, getters, equals, etc.
}

The entity class only contains an id, a firstName, and a lastName field. We can use all of the Spring Data and JPA annotations we’re familiar with. Then we’ll create the related UserRepository:

public interface UserRepository extends Repository<User, Long> {
    User save(User user);
    @Transactional(readOnly = true)
    List<User> findAll();
    List<User> findAllById(Iterable<Long> longs);
    @Query(value = "SELECT * FROM users", nativeQuery = true)
    List<User> nativeQueryFindAllUsers();
    @Query(value = "SELECT u FROM User u")
    List<User> queryFindAllUsers();
}

First, we’ll include three methods that Spring Data can translate into queries, as normal. On top of that, we’ll add two more methods annotated with @Query, one native and one non-native. This is so we see how Spring Data AOT Repository handles the different cases.

Second, we extend the Repository Interface to be more generic. The dependency we’ve included earlier will translate it to JpaRepository.

3.2. Spring Data Repositories Without AOT

Before Spring AOT optimizations and Spring Data AOT Repositories, we would compile the code by using the mvn clean install command. This would convert the Java file to a class, without any changes, except for indentation.

This means that the implementation is not generated. As we know, everything happens at runtime:

1. Spring finds the Repository interfaces
2. Passes them to the JpaRepositoryFactory
3. The JpaRepositoryFactory builds the SimpleJpaRepository instances
4. Then wraps each instance with a dynamic proxy that routes calls from your interface methods, like findAll(), to the corresponding methods on SimpleJpaRepository, or to the Query and JPQL implementations, or to any custom implementations

Everything is being built at runtime, based on reflection. This means that startup time and memory are being affected.

3.3. Repositories With AOT, Before Spring Data AOT Repositories

Spring 6 came with Ahead of Time Optimizations. To enable this feature, we need to:

• Compile the code, including the spring-boot:process-aot task, or set up the build plugin to enable AOT compilation by default
• Execute the application setting the spring.aot.enabled property to true

Regarding the Spring Data Repositories, the result is the same as before. This means that we get the same class, and then Spring uses the SimpleJpaRepository, reflection, and proxies at runtime to make everything happen. The difference is that the AOT compilation creates an additional class, the UserRepository__BeanDefinitions class, with some reflection metadata and other info precomputed at build time. This improves startup time.

3.4. Spring Data AOT Repositories

The new feature, coming with Spring Data 4, is the Spring Data AOT Repositories. With this feature, Spring is shifting all the Repository preparations that are done at application startup to build time.

Let’s see how this works, on a high level. Spring turns your Repository query methods into actual source code by relying on the store-specific nature of the repository. The methods that are already implemented are used directly. For instance, the save() method is implemented in SimpleJpaRepository, in our example. Spring doesn’t need to generate any code for such methods. However, the remaining methods will be implemented inside the UserRepositoryImpl__AotRepository class.

The way to compile the code using AOT remains the same as in the previous Spring version. We can find the generated classes in our target/classes folder:

@Generated
public class UserRepositoryImpl__AotRepository extends AotRepositoryFragmentSupport {
    private final RepositoryFactoryBeanSupport.FragmentCreationContext context;
    private final EntityManager entityManager;
    public List<User> nativeQueryFindAllUsers() {
        String var1 = "SELECT * FROM users";
        Query var2 = this.entityManager.createNativeQuery(var1, User.class);
        return var2.getResultList();
    }
    public List<User> queryFindAllUsers() {
        String var1 = "SELECT u FROM User u";
        Query var2 = this.entityManager.createQuery(var1);
        return var2.getResultList();
    }
}

Methods annotated with @Query contain the same code we would write if we weren’t using Spring Data. The UserRepository__BeanDefinitions class is present, similar to previous versions. The last source generated by this new feature is a JSON file with hints for native-image, UserRepository.json.

This way Spring generates a concrete repository implementation at build time, eliminating the proxy and most runtime reflection. This improves both the startup time and memory.

To enable usage of Spring Data AOT Repositories, we need to execute the application setting the spring.aot.repositories.enabled property to true:

mvn spring-boot:run -Dspring.aot.enabled=true -Dspring.aot.repositories.enabled=true

4. Performance Implications

Spring Data AOT Repositories are expected to improve application performance. Startup time should be reduced, and some memory consumption as well, as advertised in the relevant Spring Blog article:

Next, we’ll compare the performance of the three implementations we discussed so far:

• Spring before AOT, using the java -jar spring-data-jpa-not-aot/target/spring-data-jpa-not-aot-0.0.1-SNAPSHOT.jar command
• Spring with AOT improvements, using the java -Dspring.aot.enabled=true -jar spring-data-jpa-aot/target/spring-data-jpa-aot-0.0.1-SNAPSHOT.jar command
• Spring Data AOT Repositories, using the java -Dspring.aot.enabled=true -Dspring.aot.repositories.enabled=true -jar spring-data-jpa-aot-repository/target/spring-data-jpa-aot-repository-0.0.1-SNAPSHOT.jar command

We’ll use five entity classes and repositories to try to make the changes more visible. And we’ll focus on the startup time and memory consumption.

4.1. Build Times Comparison

As already explained, the new AOT Repositories feature performs additional work at build time to construct the Repositories. So, this means that we expect slower build times when we enable this feature:

• repositories without AOT: Total time: 11.076 s
• repositories with AOT: Total time: 17.166 s
• AOT Repositories: Total time: 25.390 s

With Spring Data AOT Repositories, if we have syntax errors in JPA methods, we see compile-time errors. This makes sense, since the transformation of JPA methods to SQL Statements now happens at compile rather than runtime.

4.2. Startup Times Comparison

Next, we’ll execute a script that starts each service, and at the same time, it starts trying to hit an endpoint that uses a repository. This way, we can monitor how long it took for the service to start, since the server and the repositories are ready for use.

For the repositories without AOT, the script output was:

==== RESULTS ====
time elapsed 10148 millis
Process Specific Memory/CPU (RSS KB / CPU Time): 289840 00:00:28

For the repositories with AOT:

==== RESULTS ====
time elapsed 9885 millis
Process Specific Memory/CPU (RSS KB / CPU Time): 291104 00:00:25

And for Spring Data AOT Repositories:

==== RESULTS ====
time elapsed 8745 millis
Process Specific Memory/CPU (RSS KB / CPU Time): 292864 00:00:23

This makes perfect sense, since we know that AOT and AOT Repositories target the improvement of startup times. And this is clear even for small projects like ours.

The memory improvement that is advertised by Spring is not shown here, but it makes sense for our small project.

Note, when starting the application without AOT, we should notice a log saying: Starting Application. But when using AOT, it should say Starting AOT-processed Application.

4.3. Comparison Under Load

Our last test includes a script that sends some traffic to each implementation and compares the performance.

For the repositories without AOT, the script output was:

==== RESULTS ====
Total requests: 6688
Success (2xx): 6688
...
Avg duration (measured): 51.7629ms
...
Max memory utilised: 331888

For the repositories with AOT:

==== RESULTS ====
Total requests: 7664
Success (2xx): 7664
...
Avg duration (measured): 43.934ms
...
Max memory utilised: 334000

And for Spring Data AOT Repositories:

==== RESULTS ====
Total requests: 6673
Success (2xx): 6673
...
Avg duration (measured): 49.0766ms
...
Max memory utilised: 337948

The result doesn’t show the memory improvement that Spring advertises, but this could be impacted by the project sizes and the data store.

5. Conclusion

In this article, we explored the new feature of Spring Boot 4, Spring Data AOT Repositories. We used a simple UserRepository class to demonstrate how Spring Data Repository worked before and what changes exactly this new feature introduced. Finally, we compared the performance implications of using the Spring Data AOT Repositories.

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

       

1. Overview

Internet Protocol version 6 or IPv6, defined in RFC 2460, is the latest generation of the Internet Protocol. It replaces the limited IPv4 address space. However, IPv6 doesn’t directly interoperate with IPv4. Because of this, devices using different protocols often face compatibility issues.

To solve this, modern systems use techniques like dual-stack, tunneling, and translation. Thus, these methods enable systems to support IPv6 while still working with IPv4. However, they primarily work at the Network Layer (Layer 3).

In many cases, developers need a way to represent IPv4 addresses in an IPv6-compatible format. So, they write code to map data between the two formats.

In this tutorial, we see how to convert an IPv4 address to IPv6 using Java.

2. What Does Converting Mean?

In reality, there is no direct conversion from IPv4 to IPv6. The two protocols differ in structure and design.

Instead, a common approach is to embed IPv4 inside IPv6. This format is called an IPv4-mapped IPv6 address.

In addition, we also have other representations. However, not all are standard today. For example, IPv4-compatible IPv6 addresses are now deprecated. In the same way, NAT64 and 6to4 act as transition methods, not true conversions.

So, let’s look at how to implement the above techniques in Java.

3. Java Implementation

In essence, Java provides built-in classes to work with IP addresses. The InetAddress class supports both IPv4 and IPv6.

3.1. Convert IPv4 to IPv6-Mapped Address

Let’s look at the case of a mapped address.

For that, we convert an IPv4 address to an IPv6 format using a standard format:

::ffff:w.x.y.z

In the above case, w.x.y.z is the target IPv4 address:

String toIpv4MappedIpv6(String ipv4Address) throws UnknownHostException {
    validateIpv4(ipv4Address);
    return "::ffff:" + ipv4Address;
}

This method simply adds the ::ffff: prefix. As a result, we get a valid IPv4-mapped IPv6 address.

3.2. IPv4-Compatible IPv6 Address

Markedly, the IPv4-compatible IPv6 address format is no longer in use. Still, it helps to understand older systems.

In hex notation, this type of address sets all the leading bits to zero.

Let’s again take the IPv4 address w.x.y.z:

0000:0000:0000:0000:0000:0000:WWXX:YYZZ

This address can also be compressed by omitting all leading zeroes:

::w.x.y.z 

Furthermore, we see its implementation:

String toIpv4CompatibleIpv6(String ipv4Address) throws UnknownHostException {
    validateIpv4(ipv4Address);
    return "::" + ipv4Address;
}

The above method takes an IPv4 address and returns an IPv6 address.

As a result, an IPv4 address, 192.0.2.33, returns IPv4-compatible IPv6 ::192.0.2.33.

3.3. NAT64 Implementation

NAT64-style translated addresses typically use a 64:ff9b::/96 prefix. It’s then followed by the target IPv4 address.

For example, an IP address of the form w.x.y.z gets the NAT64 ID 64:ff9b::w.x.y.z.

The implementation code remains the same as the last ones:

String toNat64Ipv6(String ipv4Address) throws UnknownHostException {
    validateIpv4(ipv4Address);
    return "64:ff9b::" + ipv4Address;
}

Thus, if we have an IPv4 address of 192.0.2.33, the resulting address should be 64:ff9b::192.0.2.33.

3.4. 6to4 Addresses (Tunneling)

6to4 is a transition method. It wraps IPv6 packets inside IPv4 packets. Moreover, for this purpose, Internet Assigned Numbers Authority (IANA) has assigned the 2002::/16 block.

For example, the IPv4 address 192.0.2.4 has a hexadecimal equivalent of C000:0204. The 6to4 prefix in this case becomes 2002:C000:0204::/48:

16 bits (the base) + 32 bits (the IPv4) = 48 bits

Thus, the prefix 2002::/16 is followed by the 32 bits of the public IPv4 address.

Let’s see its Java implementation:

String toSixToFourIpv6(String ipv4Address) throws UnknownHostException {
    byte[] bytes = validateAndGetBytes(ipv4Address);
    return String.format("2002:%02x%02x:%02x%02x::",
      bytes[0] & 0xff,
      bytes[1] & 0xff,
      bytes[2] & 0xff,
      bytes[3] & 0xff);
}

The above method converts each IPv4 byte into its hexadecimal representation.

Finally, the result gets appended to the 2002::/16 prefix.

4. JUnit Test

To verify the class methods, we can write a simple JUnit test:

class Ipv4ToIpv6ConverterUnitTest {
    private final Ipv4ToIpv6Converter converter = new Ipv4ToIpv6Converter();
    @Test
    void whenValidIpv4_thenReturnMappedIpv6() throws Exception {
        String result = converter.toIpv4MappedIpv6("192.168.1.1");
        assertEquals("::ffff:192.168.1.1", result);
    }
}

Thus, we can check if the output matches the expected value. In the same way, we can write tests for other methods.

5. Use Cases

IPv4-mapped IPv6 addresses help both protocols work together in dual-stack systems.

Users can also use a tunneling mechanism, like 6to4, if they don’t have dual-stack support.

Similarly, we have translators like NAT64. They also help in interoperability between an IPv4 device and an IPv6 device.

The general idea of the conversion is to enable the different protocols to work in sync.

6. Conclusion

In this article, we discussed the conversion between IPv4 and IPv6 with Java. Since both IP protocols differ in structure and semantics, we can’t truly convert IPv4 into IPv6.

Because of this, the above approaches don’t turn an IPv4 host into a native IPv6 host. Instead, they provide a way for the systems to work together. Java simplifies this process through classes like InetAddress and byte handling.

As a result, applications can support both address formats efficiently.

The complete code for this article is available over on GitHub.

       

1. Spring and Java

>> The Spring Team on Spring Framework 7 and Spring Boot 4 [infoq.com]

A walk through what’s landed in Spring Framework 7 and Spring Boot 4 – the direction, the rationale, and what it means for the ecosystem. Good overview.

Also worth reading:

• >> Quality Outreach Heads-up – JDK 27: Obsolete Translation Resources Removed [inside.java]
• >> Using Spring Data JDBC With Kotlin [jetbrains.com]
• >> How I Automated Weekly Twitter/X Posts With Java, JBang and GitHub Actions [foojay.io]
• >> BoxLang AI Deep Dive — Part 1 of 7: The Skills Revolution [foojay.io]
• >> Enabling reflection-free Jackson serializers by default [quarkus.io]
• >> Spring AI Agentic Patterns (Part 7): Session API — Event-Sourced Short-Term Memory with Context Compaction [spring.io]

Webinars and presentations:

• >> Foojay Podcast #93: Update Your JDK, Read More Code, and Talk to Your Users: Interviews From VoxxedDays Amsterdam [foojay.io]
• >> Episode 54 “How JDK 26 Improves G1’s Throughput” [AtA] [inside.java]
• >> A Bootiful Podcast: Mark Kropf on AI orchestration [spring.io]

Time to upgrade:

• >> Oracle Java Extension for Visual Studio Code Version 25.1.0 Is Now Available [inside.java]
• >> Elasticsearch 9.3.3, 9.2.8 and 8.19.14 [github.com/elastic]
• >> Grails 7.1.0 [github.com/grails]
• >> Micronaut Core 4.10.21 [github.com/micronaut-projects]
• >> Helidon 4.4.1 [github.com/oracle]
• >> Camel 4.19.0, 4.18.2 and 4.14.6 [github.com/apache]
• >> Payara Platform Community 7.2026.4 [github.com/payara]
• >> Micrometer 1.16.5 and 1.15.11 [github.com/micrometer-metrics]

2. Technical & Musings

>> A GitHub agentic workflow [frankel.ch]

A hands-on walkthrough of wiring an agentic workflow into GitHub – using issues and PRs as the coordination surface. Weekend reading.

Also worth reading:

• >> The Center Has a Bias [lucumr.pocoo.org]
• >> When You Can Safely Leave Sprints Behind [jbrains.ca]
• >> Anti-patterns in event modelling – Passive-Aggressive Events [event-driven.io]
• >> Evaluating Netflix Show Synopses with LLM-as-a-Judge [netflixtechblog.com]

3. Pick of the Week

>> How to do what you love and make good money [sive.rs]

       

1. Overview

When we work with regular expressions in Java, even a small syntax mistake can break our application at runtime. One of the most common errors we encounter is:

java.util.regex.PatternSyntaxException: Unclosed character class

In this tutorial, we’ll explore why this happens, how to reproduce it, and how to fix it. We also cover a real-world issue involving split() that often triggers this exception.

2. Understanding Character Classes

A character class in regex allows us to match any one character from a given set. This is one of the most commonly used regex constructs in Java.
Let us first look at a simple example of a character class:

"[abc]"

In this pattern, the regex engine matches either a, b, or c. We should always remember that a character class starts with [ and must end with ]. We can also define ranges when working with larger sets of characters:

"[a-z]"

This pattern matches any lowercase English letter from a to z. If we forget to close the bracket, Java will throw a runtime exception.

3. Reproducing the Exception

To better understand the problem, let us intentionally write an invalid regex pattern. This helps us see exactly how Java reacts:

public class RegexExample {
    public static void main(String[] args) {
        Pattern.compile("[a-z");
    }
}

In the above example, we try to compile a regex that starts a character class but never closes it. When we run this code, Java throws the following exception:

java.util.regex.PatternSyntaxException: Unclosed character class near index 4
[a-z
    ^

This clearly indicates that the regex parser expected a closing ] but did not find one.

4. Fixing the Exception

Now that we understand the problem, fixing it becomes straightforward. We simply need to close the character class properly:

Pattern.compile("[a-z]");

After making this change, the pattern compiles successfully without any errors. We should always verify that every opening bracket has a corresponding closing bracket.

5. Common Causes of This Exception

Let’s have a look at some of the common causes of PatternSyntaxException.

5.1. Missing Closing Bracket

One of the most frequent mistakes is forgetting to close the character class:

Pattern.compile("[0-9");

This pattern is incomplete and results in a runtime exception. We can fix it by adding the missing closing bracket:

Pattern.compile("[0-9]");

Even a small omission like this can break the entire regex.

5.2. Incorrect Nested Patterns

Sometimes, while writing a complex regex, we accidentally introduce extra brackets:

Pattern.compile("[a-zA-Z[0-9]");

In this pattern, we have an extra [ inside the character class. Character classes do not support nesting using [ like this, so the regex becomes invalid. As a result, Java throws a PatternSyntaxException.

To fix this, we should remove the unnecessary bracket and define the character set correctly:

Pattern.compile("[a-zA-Z0-9]");

Now the pattern is valid and matches any alphanumeric character. Instead of nesting, we should combine all required characters within a single character class.

6. Issue with split()

Let us now look at a practical example that often causes confusion in real projects. Before jumping into the issue, we first define a sample 2D array.

String[][] array2d = {
    {"a", "b"},
    {"c", "d"}
};

In many cases, we convert this array into a string using Arrays.deepToString() for quick inspection or processing:

String str = Arrays.deepToString(array2d);
System.out.println(str);

When we run this, the output looks like:

[[a, b], [c, d]]

Notice that the output contains nested square brackets. This is important for understanding the issue. Now, let us attempt to split this string into individual rows. At first glance, the following code looks correct:

String[][] split = new String[1][rows];
split[0] = str.split("], [");

However, when we run this code, we encounter a runtime exception:

java.util.regex.PatternSyntaxException: Unclosed character class

This happens because split() expects a regex, not a plain string. The pattern: “], [” is interpreted incorrectly, since [ and ] are special characters in regex. As a result, the regex engine treats [ as the start of a character class, leading to the exception.
To resolve this issue, we need to escape the square brackets so they are treated as literal characters:

split[0] = str.split("\\], \\[");

With this change, the regex becomes valid, and the code works as expected. Proper escaping ensures that special characters do not break our regex. Although the fix works, we can further improve the solution for cleaner output. The result of Arrays.deepToString() contains outer brackets that we may want to remove:

String str = Arrays.deepToString(array2d);
str = str.substring(1, str.length() - 1);
String[] result = str.split("\\], \\[");

By trimming the outer brackets, we get a cleaner split result. This makes the output easier to process and avoids unwanted characters.

7. Conclusion

In this article, we saw that the PatternSyntaxException: Unclosed character class is a common yet avoidable issue in Java. It usually occurs due to missing brackets or incorrect handling of special characters like [ and ]. By carefully writing regex patterns, properly escaping characters in methods like split(), and validating inputs, we can build more reliable applications. A small attention to detail in regex can prevent major runtime issues.

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

       

1. Overview

Spring Boot allows us to easily schedule a job, for example, using the @Scheduled annotation. Sometimes, we don’t want to hardcode the scheduling parameters, such as the cron expression. Instead, we would like to schedule a job using a cron expression from a database.

In this tutorial, we’ll first explore two approaches to achieve it. Further, we’ll discuss when to use which.

2. Introduction to the Problem

When we work with Spring scheduling, the most straightforward option is usually to place the cron expression directly in @Scheduled, for example:

@Scheduled(cron = "*/5 * * * * ?")
public void run() {
    // job logic
}

This works well, but it also hardcodes the schedule into the application.

The problem appears when we want to fetch the cron expression from a database. This is because we cannot simply write something like this:

private String cronExpression = loadFromDatabase();
@Scheduled(cron = cronExpression)
public void run() {
    // invalid approach
}

If we compile this code, the compiler will complain:

java: element value must be a constant expression

The reason is that the cron attribute in an annotation cannot be populated from an arbitrary runtime variable. In practice, we either need an indirection that Spring can resolve for us, or we need to move away from annotation-driven scheduling altogether.

In this tutorial, we’ll explore both approaches. But let’s do some preparation before we dive into the solutions.

3. Preparing Data in a Database

For this tutorial, we use a small H2 in-memory database. Also, for simplicity, we’ll skip Spring Data JPA configurations

3.1. Creating a Simple Table

We want our Spring Boot application to automatically create a database table and insert some data into it when it starts. Therefore, let’s prepare a schema.sql file:

CREATE TABLE IF NOT EXISTS cron_config (
    id BIGINT PRIMARY KEY,
    cron_expression VARCHAR(255) NOT NULL
);

As we can see, the cron_config table is intentionally minimal. We only need an identifier and the cron expression itself.

Next, let’s create a data.sql file to insert a row into the table:

INSERT INTO cron_config (id, cron_expression) VALUES (1, '*/5 * * * * ?');

We insert a single row so the application has a cron value as soon as it starts. So by default, the schedule runs every five seconds.

3.2. Preparing the Entity and the Repository Classes

The corresponding JPA entity is equally small:

@Entity
@Table(name = "cron_config")
public class CronEntity {
    @Id
    private Long id;
    private String cronExpression;
    // ... the default constructor, getters and setters are omitted
}

The repository is just as simple and gives us the CRUD operations we need:

public interface CronConfigRepository extends JpaRepository<CronEntity, Long> {
}

With these pieces in place, we can read and update cron values from the database.

Now, let’s see how to tell Spring to schedule jobs using the cron expression we stored in the database.

4. Using a cronLoader Bean

In our first approach, we would like to keep the @Scheduled annotation, but avoid placing the cron expression directly in the annotation. Instead, we’ll create a Spring Bean to read the cron expression from our database and reference the bean in @Scheduled’s cron attribute.

4.1. Defining the cronLoader Bean to Load the Cron Expression

We start with a small configuration class that defines a bean named cronLoader:

@Configuration
public class CronLoaderConfig {
    @Bean
    String cronLoader(CronConfigRepository repository) {
        return repository.findById(1L)
          .map(CronEntity::getCronExpression)
          .orElseThrow(() -> new RuntimeException("Cron expression not found in DB"));
    }
}

As the code above shows, this bean is pretty straightforward. It reads the cron expression from the row with id = 1 and returns it as a String.

4.2. Referencing the Bean from @Scheduled

Next, we can reference that bean through SpEL in our scheduled job:

@Component
public class AnnotationScheduledJob {
    private static final Logger log = LoggerFactory.getLogger(AnnotationScheduledJob.class);
    @Scheduled(cron = "#{@cronLoader}")
    public void run() {
        log.info("✅ [{}] Job executed - cron loaded from DB via @Scheduled", now());
    }
}

This is the key idea: we still use @Scheduled, but the cron expression comes from the cronLoader bean instead of being embedded directly in the annotation.

Also, our job does nothing but print a line with the execution time, so we can verify whether the executions match our cron expression in the database.

Next, let’s verify if the job scheduling works as we expected.

4.3. Starting the Application and Observing the Console Outputs

If we start our Spring Boot application, we can see these lines in the console log:

...
... AnnotationScheduledJob : ✅ [10:00:05.002] Job executed - cron loaded from DB via @Scheduled
... AnnotationScheduledJob : ✅ [10:00:10.001] Job executed - cron loaded from DB via @Scheduled
... AnnotationScheduledJob : ✅ [10:00:15.000] Job executed - cron loaded from DB via @Scheduled
... AnnotationScheduledJob : ✅ [10:00:20.001] Job executed - cron loaded from DB via @Scheduled
...

Because our data.sql inserts “*/5 * * * * ?” as the cron expression, we see the annotation-based job log roughly every five seconds. This gives us a straightforward way to verify that the cron value is being loaded from the database.

4.4. Limitation of the cronLoader Bean Approach

This approach is convenient, but it comes with an important limitation.

Spring loads the cron value when it creates the cronLoader bean during application startup. After that, the scheduled method continues using the resolved value.

If we update the cron_config table later, the schedule won’t automatically change for the running application. In practice, we would typically need to restart the application to pick up the new value.

So, this approach is a good fit only when loading the schedule once at startup is acceptable.

5. Using Spring’s SchedulingConfigurer

If we want our scheduled jobs to react to database changes without restarting, we need a more dynamic solution. Next, let’s dive in.

5.1. Implementing SchedulingConfigurer

Instead of relying on the @Scheduled annotation, we can implement Spring’s SchedulingConfigurer and register our own trigger task.

First, let’s create a DynamicScheduledConfig configuration class implementing SchedulingConfigurer:

@Configuration
public class DynamicScheduledConfig implements SchedulingConfigurer {
    private static final Logger log = LoggerFactory.getLogger(DynamicScheduledConfig.class);
    private final CronConfigRepository repository;
    public DynamicScheduledConfig(CronConfigRepository repository) {
        this.repository = repository;
    }
    @Override
    public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
        taskRegistrar.addTriggerTask(() -> log.info(
          "✅ [{}] DynamicScheduledConfig executed - cron re-read from DB per execution",
          now()), triggerContext -> {
            String cronExpression = repository.findById(1L)
              .map(CronEntity::getCronExpression)
              .orElseThrow(() -> new RuntimeException("Cron expression not found in DB"));
            return new CronTrigger(cronExpression).nextExecution(triggerContext);
        });
    }
}

Next, let’s understand how the configureTasks() method works:

First, we register a task with the addTriggerTask(…) method. The addTriggerTask() method has two parameters: a Runnable (the “What”) that contains the work we want to execute in this task and a Trigger object (the “When”) that specifies when the task should be triggered.

In our example, our task simply prints a log with the current time.

The Trigger parameter is the “magic” part of the implementation. It calculates the next execution time every time the task finishes:

• Fetching the cron expression from our database using the injected repository
• Creating a new CronTrigger object from the cron expression on the fly, and Spring asks that trigger for the next execution time

This means that if we change the cron expression in our database, the trigger callback will pick up the new value immediately when it calculates the next execution time. This is the main difference from the cronLoader bean approach: the cron expression is re-read from the database whenever Spring calculates the next execution time.

5.2. A Simple REST Controller to Update the Cron Expression in Our Database

For easier testing, let’s create a simple REST controller that allows us to quickly update the database record by HTTP request:

@RestController
public class CronController {
    private static final Logger log = LoggerFactory.getLogger(CronController.class);
    private final CronConfigRepository repository;
    public CronController(CronConfigRepository repository) {
        this.repository = repository;
    }
    @GetMapping("/cron")
    public String updateCron() {
        CronEntity cronEntity = repository.findById(1L)
          .orElseThrow(() -> new RuntimeException("Cron expression not found in database"));
        cronEntity.setCronExpression("*/10 * * * * ?");
        repository.save(cronEntity);
        String msg = "[DB] ⏰ Updated cron expression in DB to: */10 * * * * ?";
        log.info(msg);
        return msg;
    }
}

As the example shows, for simplicity, this endpoint always sets the cron to run every 10 seconds.

Next, let’s verify if the SchedulingConfigurer approach can always reschedule the job according to the database change.

5.3. Starting the Application and Observing the Console Outputs

To make the logs easier to read during the demonstration, we can temporarily comment out the annotation-based scheduling line in AnnotationScheduledJob so that only the dynamic task is running:

@Component
public class AnnotationScheduledJob {
    // ...
    // @Scheduled(cron = "#{@cronLoader}")  <-- comment out
    public void run() {
        // ...
    }
}

Next, let’s launch our Spring Boot application. Once it starts, the scheduled job will also begin. Log outputs similar to these will appear in the console:

... DynamicScheduledConfig : ✅ [10:05:05.001] DynamicScheduledConfig executed - cron re-read from DB per execution
... DynamicScheduledConfig : ✅ [10:05:10.001] DynamicScheduledConfig executed - cron re-read from DB per execution
... DynamicScheduledConfig : ✅ [10:05:15.001] DynamicScheduledConfig executed - cron re-read from DB per execution
... DynamicScheduledConfig : ✅ [10:05:20.000] DynamicScheduledConfig executed - cron re-read from DB per execution

Because the data.sql file still seeds “*/5 * * * * ?”, the dynamic task initially runs about every five seconds.

Next, let’s call the “/cron” endpoint to update the cron expression. For example, we can launch this curl command to send a GET request:

curl http://localhost:8080/cron

Then, in the Spring Boot application console, we can see this log, meaning the cron expression has been changed to “every 10 seconds”:

... CronController : [DB] ⏰ Updated cron expression in DB to: */10 * * * * ?

After that, the dynamic task should start following the new interval. In other words, instead of firing every five seconds, subsequent executions should move to a ten-second rhythm:

... DynamicScheduledConfig : ✅ [10:05:30.000] DynamicScheduledConfig executed - cron re-read from DB per execution
... DynamicScheduledConfig : ✅ [10:05:40.002] DynamicScheduledConfig executed - cron re-read from DB per execution
... DynamicScheduledConfig : ✅ [10:05:50.000] DynamicScheduledConfig executed - cron re-read from DB per execution
... DynamicScheduledConfig : ✅ [10:05:60.000] DynamicScheduledConfig executed - cron re-read from DB per execution

This demonstrates the main benefit of SchedulingConfigurer: we can change the cron expression in the database and let the running application adapt without a restart.

6. Conclusion

In this article, we explored two ways to get a scheduled job’s cron value from a database in Spring Boot.

With the cronLoader bean approach, we keep the implementation simple and continue using @Scheduled, but we only load the cron value once during startup.

With SchedulingConfigurer, we take control of task registration and re-read the cron expression from the database whenever Spring calculates the next execution time. This makes the schedule dynamic and allows runtime updates.

So if we only need a startup-time value, a bean-backed @Scheduled setup is often enough. But if we want truly dynamic scheduling, SchedulingConfigurer is the better choice.

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

       

1. Introduction

Gaussian blur is a widely used image processing technique for reducing image noise and detail. However, achieving accurate Gaussian blur can be computationally expensive, especially for high-resolution images with large blur radii.

In this tutorial, we’ll explore a faster, more computationally efficient solution for implementing Gaussian blur in Java.

2. Problem Overview

We implement a standard Gaussian blur on a grayscale image by convolving it with a 2D Gaussian kernel. Here, for each pixel in an image, the algorithm first examines a surrounding grid of pixels (the kernel). Then, it multiplies each pixel’s intensity by a specific weight. Finally, it sums them up.

For an image with n pixels and a blur radius of r, our kernel size is (2r + 1)  x  (2r + 1). Thus, the standard 2D convolution algorithm has a time complexity of O(n.r²). As the blur radius r grows, the performance degrades quadratically. Thus, it is not optimal for real-time processing over large images.

3. The Fast Approximation Algorithm

Our fast approximations make two key enhancements to the standard Gaussian 2D blur method.

3.1. Separable Filters

A 2D Gaussian kernel can be seen and used as two 1D Gaussian vectors. In other words, we can separate them as horizontal and vertical vectors. So, instead of applying a 2D matrix to every pixel of the image, we can achieve the same result by applying a horizontal 1D blur across all rows, followed by a vertical 1D blur down all columns.

This simple separation reduces our average-case time complexity from O(n.r²) to O(n.r).

3.2. Repeated Box Blurs

We repeat a specific blur operation (box blur) to achieve the desired effect.

We define box blur as the simplest form of blurring, assigning equal weight to every pixel within the blur radius. Then, we make use of the Central Limit Theorem to approximate a valid and matching Gaussian distribution. According to the Central Limit Theorem, applying a simple Box Blur multiple times closely approximates an accurate Gaussian distribution. We run five consecutive passes of a box blur to get a visually indistinguishable result from a strict Gaussian blur with a fraction of the computational overhead.

Furthermore, we make all weights in a Box Blur equal, so we don’t need to re-sum the entire radius for every pixel. This gives us the freedom to use a sliding window or a moving average. As the window shifts to the right by one pixel, we subtract the leaving pixel and add the entering pixel. This drops our average time complexity to O(n), making the performance entirely independent of the blur radius r!

4. Solution

Let’s move to the solution.

4.1. The Sliding Window Box Blur

First, we define a function, horizontalBoxBlur(), that performs a 1D horizontal blur using the sliding-window technique.

Here, we process the image row by row. We don’t recalculate the pixel sum at every position. Instead, we initialize windowSum for the very first pixel in a row. As it moves left to right, it subtracts the value of the pixel beyond the trailing edge of the radius and adds the value of the pixel at the leading edge.

Lastly, we clamp edges to ensure that if the radius extends beyond the image boundaries, our logic duplicates the edge pixels rather than throwing an ArrayIndexOutOfBoundsException.

private static void horizontalBoxBlur(int[] source, int[] target, int width, int height, int radius) {
    double scale = 1.0 / (radius * 2 + 1);
    for (int y = 0; y < height; y++) {
        int windowSum = 0;
        int offset = y * width;        
        for (int x = -radius; x <= radius; x++) {
            int safeX = Math.min(Math.max(x, 0), width - 1);
            windowSum += source[offset + safeX];
        }        
        for (int x = 0; x < width; x++) {
            target[offset + x] = (int) Math.round(windowSum * scale);
            int leftX = Math.max(x - radius, 0);
            int rightX = Math.min(x + radius + 1, width - 1);
            windowSum -= source[offset + leftX];
            windowSum += source[offset + rightX];
        }
    }
}

The verticalBoxBlur() is identical in logic, but here we traverse columns rather than rows (top to bottom):

private static void verticalBoxBlur(int[] source, int[] target, int width, int height, int radius) {
    double scale = 1.0 / (radius * 2 + 1);
    for (int x = 0; x < width; x++) {
        int windowSum = 0;
        for (int y = -radius; y <= radius; y++) {
            int safeY = Math.min(Math.max(y, 0), height - 1);
            windowSum += source[safeY * width + x];
        }
        for (int y = 0; y < height; y++) {
            target[y * width + x] = (int) Math.round(windowSum * scale);
            int topY = Math.max(y - radius, 0);
            int bottomY = Math.min(y + radius + 1, height - 1);
            windowSum -= source[topY * width + x];
            windowSum += source[bottomY * width + x];
        }
    }
}

4.2.  Integration

This is our orchestrator.

Leveraging the Central Limit Theorem, we apply a horizontal and vertical box blur three times (configurable). This smooths out peaky regions, thus creating a near-perfect approximation of a true Gaussian bell curve. It uses a temp array (temp) to safely ping-pong the data between passes without corrupting the source:

public static int[] applyFastGaussianBlur(int[] source, int numPasses, int width, int height, int radius) {
    int[] target = new int[source.length];
    int[] temp = new int[source.length];
    System.arraycopy(source, 0, target, 0, source.length);
    for (int i = 0; i < numPasses; i++) {
        horizontalBoxBlur(target, temp, width, height, radius);
        verticalBoxBlur(temp, target, width, height, radius);
    }
    return target;
}

5. Test

5.1. Test Using Impulse Image

First, let’s test this method using an impulse image (artificial images with a single black pixel). Our main objective is to verify if  our algorithm handles edges correctly and applies a smoothing effect:

void givenSharpImage_whenAppliedBlur_thenCenterIsSmoothed() {
    int width = 5;
    int height = 5;
    int numPasses = 5;
    int[] image = new int[width * height];
    image[12] = 255; 
    int[] blurredImage = FastGaussianBlur.applyFastGaussianBlur(image, numPasses, width, height, 1);
    assertTrue(blurredImage[12] < 255);
    assertTrue(blurredImage[12] > 0);
    assertTrue(blurredImage[11] > 0); // Left neighbor
    assertTrue(blurredImage[13] > 0); // Right neighbor
}

We begin by creating a 5×5 image (25 pixels) and set all pixels to 0, making them pure black. Then we set the exact center pixel (index 12) to 255, making it pure white. This sharp point is our impulse or peak. Then we apply the fast blur algorithm with a radius of 1.

Our main claim is that blur, when applied correctly, spreads the brightness of the central pixel outwards into the surrounding black pixels. Further, assertTrue(blurredImage[12] < 255) confirms the center pixel has dimmed because it shared its brightness, and assertTrue(blurredImage[11] > 0) and assertTrue(blurredImage[13] > 0) confirm that the immediate left and right neighbors (both black) have absorbed that dispersed brightness.

5.2. Test Using Real Image

We take an open-source image and blur it using our algorithm. Here is the sample image:

Please check the blurred version:

We used a single channel of integer values for our impulse image (grayscale) test case. For this case, we use real images. Each real image is packed with 32-bit ARGB (Alpha, Red, Green, Blue) data. So, here we extract the ARGB channels, then blur each of the RGB channels independently, and finally pack them back together:

public static BufferedImage blurRealImage(@Nonnull BufferedImage image, int radius, int numPasses) {
    int width = image.getWidth();
    int height = image.getHeight();
    int[] pixels = image.getRGB(0, 0, width, height, null, 0, width);
    int[] a = new int[pixels.length];
    int[] r = new int[pixels.length];
    int[] g = new int[pixels.length];
    int[] b = new int[pixels.length];
    for (int i = 0; i < pixels.length; i++) {
        a[i] = (pixels[i] >> 24) & 0xff;
        r[i] = (pixels[i] >> 16) & 0xff;
        g[i] = (pixels[i] >> 8) & 0xff;
        b[i] = pixels[i] & 0xff;
    }
    r = FastGaussianBlur.applyFastGaussianBlur(r, width, height, radius, numPasses);
    g = FastGaussianBlur.applyFastGaussianBlur(g, width, height, radius, numPasses);
    b = FastGaussianBlur.applyFastGaussianBlur(b, width, height, radius, numPasses);
    int[] resultPixels = new int[pixels.length];
    for (int i = 0; i < pixels.length; i++) {
        resultPixels[i] = (a[i] << 24) | (r[i] << 16) | (g[i] << 8) | b[i];
    }
    BufferedImage result = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB);
    result.setRGB(0, 0, width, height, resultPixels, 0, width);
    return result;
}

6. Conclusion

In this article, we learned a faster Gaussian blur method in Java. We made two key enhancements to the standard Gaussian blur implementation to achieve linear time complexity. First, we decomposed a 2D convolution matrix into separable 1D arrays, and second, we used a moving-average sliding window across three box-blur passes. Thus, our solution works in a constant processing time that is independent of the blur radius.

As always, the complete code examples are available over on GitHub.

       

1. Spring and Java

>> Beyond RAG: Architecting Context-Aware AI Systems with Spring Boot [infoq.com]

A solid look at Context-Augmented Generation (CAG) — an architectural layer on top of RAG that adds user identity, session state, and business constraints before the retrieval step. With Boot of course.

Also worth reading:

• >> Thread-Safe Native Memory in Java: VarHandle Access Modes Explained [foojay.io]
• >> From Zero to Full Observability with Dash0 [foojay.io]
• >> Does Java Really Use Too Much Memory? Let’s Look at the Facts (JEPs) [foojay.io]
• >> Spring AI Agentic Patterns (Part 6): AutoMemoryTools — Persistent Agent Memory Across Sessions [spring.io]
• >> Announcing ADK for Java 1.0.0: Building the Future of AI Agents in Java [googleblog.com]
• >> ACP Java SDK: Building IDE Agents in Java [blog.pollack.ai]

Webinars and presentations:

• >> A Bootiful Podcast: Java developer advocate Ana-Maria Mihalceanu [spring.io]
• >> Java and Post-Quantum Cryptography [inside.java]
• >> Episode 53 “Analyzing Crashed JVMs” [inside.java]

Time to upgrade:

• >> Spring Cloud 2025.0.2 (aka Northfields) Has Been Released [spring.io]
• >> Hibernate 7.3.0.Final [in.relation.to]
• >> Helidon 4.4.0 Introduces Alignment with OpenJDK Cadence and Support via Java Verified Portfolio [infoq.com]
• >> Quarkus 3.34.3 [github.com/quarkusio]
• >> Elasticsearch 9.3.3, 9.2.8, and 8.19.14 [github.com/elastic]
• >> TornadoVM 4.0.0 [github.com/beehive-lab]
• >> Netflix Zuul 3.5.8 [github.com/Netflix]

2. Technical & Musings

>> S3 Files and the changing face of S3 [allthingsdistributed.com]

AWS’s new S3 Files feature mounts S3 buckets as network filesystems via EFS, letting you use standard file operations on object storage without copying data around. Bout time

Also worth reading:

• >> Feedback Flywheel [martinfowler.com]
• >> Harness engineering for coding agent users [martinfowler.com]
• >> Experimenting with AI subagents [frankel.ch]
• >> Absurd In Production [lucumr.pocoo.org]
• >> Synchronizing the Senses: Powering Multimodal Intelligence for Video Search [netflixtechblog.com]

3. Pick of the Week

>> Do Things that Don’t Scale [paulgraham.com]

       

1. Introduction

When consuming RESTful services in Spring, RestTemplate is a reliable workhorse for synchronous HTTP communication. However, one of the most common and frustrating hurdles developers face is the RestClientException. Specifically, the following error message:

Could not extract response: no suitable HttpMessageConverter found for response type and content type...

This error typically occurs when the client receives a response that it doesn’t know how to deserialize into the desired Java object. In this article, we’ll explore why this happens and how to configure our application to handle non-standard API responses effectively without encountering any such errors.

2. Project Setup

To get started, we’ll need the standard Spring Boot Starter Web dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>4.0.5</version>
</dependency>

For JSON processing, Spring Boot includes Jackson by default. To better understand it, we’ll ensure jackson-databind is on our classpath, as it provides the underlying logic for the MappingJackson2HttpMessageConverter.

3. Understanding and Identifying the Root Cause

To fix this error, we’ll first understand how Spring maps the raw HTTP response to Java objects. The issue is rarely with the data itself, but rather a mismatch in the expected communication protocol. We’ll now examine the internal conversion mechanism, identify common misleading media types, and learn how to inspect the actual response headers.

3.1. How RestTemplate Converts Responses

RestTemplate relies on a list of HttpMessageConverter beans to transform HTTP request and response bodies. When a response arrives, Spring looks at the Content-Type header sent by the server. It then iterates through its registered converters to find one that supports both that MediaType and the target Java class.

3.2. Common Mismatched Media Types

The issue usually isn’t that the data is invalid, but that the metadata is misleading. Many legacy or third-party APIs return valid JSON, but set the Content-Type header to something other than application/json. Common mismatched types include text/plain, text/javascript, and application/octet-stream.

The default MappingJackson2HttpMessageConverter only claims to support application/json and application/*+json. It ignores any other type of responses, leading to the “Could not extract response: no suitable HttpMessageConverter found for response type and content type” error.

3.3. Checking API Response Headers

To diagnose this, we must inspect the headers. If we can’t access external logs, we can enable debug logging for Spring Web in our application.properties:

logging.level.org.springframework.web.client.RestTemplate=DEBUG

This will reveal the exact Content-Type the server is providing, allowing us to target the specific mismatch.

4. Solving the Error: Configuration Strategies

In this section, we’ll create a config class named RestTemplateConverterConfig to inject the RestTemplate bean, which will help us resolve this error. The following section mentions the details on it:

4.1. Adding Support for Custom Media Types

The most surgical fix is to tell the Jackson converter to treat these uncommon media types as JSON. We can create an instance of MappingJackson2HttpMessageConverter and update its supported media types:

@Configuration
public class RestTemplateConverterConfig {
    @Bean("specificMediaTypesRestTemplate")
    public RestTemplate specificMediaTypesRestTemplate() {
        RestTemplate restTemplate = new RestTemplate();
        List<HttpMessageConverter<?>> converters = restTemplate.getMessageConverters();
        MappingJackson2HttpMessageConverter jsonConverter = new MappingJackson2HttpMessageConverter();
        jsonConverter.setSupportedMediaTypes(Arrays.asList(
          MediaType.APPLICATION_JSON,
          MediaType.TEXT_PLAIN,
          MediaType.valueOf("text/javascript")
        ));
        converters.add(jsonConverter);
        restTemplate.setMessageConverters(converters);
        return restTemplate;
    }
}

Here we explicitly list only the media types we expect to encounter. This keeps the converter’s scope narrow and intentional. Other unexpected content types, such as application/octet-stream, would still fail, which is often the desired behavior in a controlled environment.

4.2. Manually Registering Converters in RestTemplate

If we want a more permissive setup, within the same RestTemplateConverterConfig class, we’ll register another Jackson converter with MediaType.ALL. This instructs the RestTemplate to handle any content type the server returns:

@Bean
public RestTemplate restTemplate() {
    RestTemplate restTemplate = new RestTemplate();
    List<HttpMessageConverter<?>> converters = restTemplate.getMessageConverters();
    MappingJackson2HttpMessageConverter jsonConverter = new MappingJackson2HttpMessageConverter();
    jsonConverter.setSupportedMediaTypes(Collections.singletonList(MediaType.ALL));
    converters.add(jsonConverter);
    restTemplate.setMessageConverters(converters);
    return restTemplate;
}

Here, we call the getMessageConverters() method and append to the existing list rather than replacing it. This preserves all the default converters Spring registers, such as those for String and byte[], and simply adds our custom Jackson converter at the end.

4.3. Using RestTemplate.exchange() With ParameterizedTypeReference

Sometimes the error arises because we are trying to deserialize into a generic collection, like List<User>. In this example, the User class is a simple POJO with id and name fields that Jackson maps from the JSON response.

Using getForObject() with List.class loses generic type information at runtime due to type erasure. Instead, we should use the restTemplate.exchange() method with a ParameterizedTypeReference:

ResponseEntity<List<User>> response = restTemplate.exchange(
  "/users",
  HttpMethod.GET,
  null,
  new ParameterizedTypeReference<List<User>>() {}
);

The anonymous subclass of ParameterizedTypeReference captures the full generic type List<User> at compile time, giving Jackson enough information to correctly deserialize each element in the array into a User object.

5. Testing and Verification

To verify our configurations, we’ll use MockRestServiceServer. This allows us to simulate the exact mismatched header scenarios that typically trigger the RestClientException without needing a live external API.

5.1. Testing the Surgical Fix

In this first scenario, we use the @Qualifier to inject our specificMediaTypesRestTemplate. We’ll simulate a response that is explicitly labeled as text/plain. This proves that our surgical inclusion of that specific media type works as intended:

@Autowired
@Qualifier("specificMediaTypesRestTemplate")
private RestTemplate specificMediaTypesRestTemplate;
@Test
void givenSpecificMediaTypesRestTemplate_whenTextPlainResponse_thenDeserializeCorrectly() {
    MockRestServiceServer mockServer = MockRestServiceServer.createServer(specificMediaTypesRestTemplate);
    mockServer.expect(requestTo("/user"))
      .andRespond(withSuccess("{\"id\":1,\"name\":\"Sudarshan\"}", MediaType.TEXT_PLAIN));
    User user = specificMediaTypesRestTemplate.getForObject("/user", User.class);
    assertNotNull(user);
    assertEquals("Sudarshan", user.getName());
}

5.2. Testing the Permissive Fix

Next, we test the primary RestTemplate bean configured with MediaType.ALL. This test confirms that, by making the converter permissive, it ignores the misleading text/plain header and defaults to Jackson for deserialization.

@Test
void givenMockServer_whenTextPlainResponse_thenDeserializeCorrectly() {
    MockRestServiceServer mockServer = MockRestServiceServer.createServer(restTemplate);
    mockServer.expect(requestTo("/user"))
      .andRespond(withSuccess("{\"id\":1,\"name\":\"Sudarshan\"}", MediaType.TEXT_PLAIN));
    User user = restTemplate.getForObject("/user", User.class);
    assertNotNull(user);
    assertEquals("Sudarshan", user.getName());
}

5.3. Verifying Generic Type Resolution

Finally, we verify that our restTemplate.exchange() strategy correctly handles collections. Even with a mismatched text/plain header, the ParameterizedTypeReference ensures that the generic information List<User> is preserved during the conversion process:

@Test
void givenMockServer_whenTextPlainResponseForList_thenDeserializeWithParameterizedTypeReference() {
    MockRestServiceServer mockServer = MockRestServiceServer.createServer(restTemplate);
    mockServer.expect(requestTo("/users"))
      .andRespond(
        withSuccess(
          "[{\"id\":1,\"name\":\"Sudarshan\"},{\"id\":2,\"name\":\"Baeldung\"}]",
          MediaType.TEXT_PLAIN));
    ResponseEntity<List<User>> response = restTemplate.exchange(
      "/users",
      HttpMethod.GET,
      null,
      new ParameterizedTypeReference<List<User>>() {}
    );
    assertNotNull(response.getBody());
    assertEquals(2, response.getBody().size());
    assertEquals("Sudarshan", response.getBody().get(0).getName());
}

6. Conclusion

In this tutorial, we understood that the “No Suitable HttpMessageConverter” error is rarely a sign of broken data; it’s a communication breakdown between the server’s headers and the client’s expectations. By identifying the returned Content-Type and explicitly configuring our MappingJackson2HttpMessageConverter to support it, we can bridge this gap.

Whether you choose to support all media types via MediaType.ALL or strictly list the exceptions, like text/plain, understanding the converter registration process is key to building resilient Spring clients.

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

       

1. Overview

Bit manipulation is a fundamental concept in programming that involves working with individual bits of binary data. One common operation is flipping all bits in an integer, converting every 0 to 1 and every 1 to 0.

In this tutorial, we’ll explain what bit flipping means and explore several Java methods to flip the bits of an integer. For completeness, we’ll cover both full 32-bit flipping and flipping only the significant bits.

2. Understanding Bit Flipping

Before we learn how to flip bits in an integer, it’s best to look at a visual example.

To begin with, let’s consider the decimal number 21 and, more specifically, its binary representation:

10101

The goal is to invert each bit so that every 0 becomes a 1 and every 1 becomes a 0:

01010

This corresponds to the decimal value 10 (8+2).

During this transformation, each bit at position i in the original number gets inverted in the result. However, there’s an important distinction to make. When we flip all 32 bits of an integer, i.e., its full size, the result differs from flipping only the significant bits. For instance, flipping all 32 bits of the integer 21 produces -22 due to two’s complement representation, whereas flipping only the significant bits (10101 -> 01010) yields 10.

In the following sections, let’s explore both scenarios in detail.

3. Using the Bitwise NOT Operator

The most direct approach to flip bits is the bitwise NOT operator ~. This unary operator inverts every bit in the integer’s binary representation:

public static int flipAllBits(int n) {
    return ~n;
}

The operator flips all 32 bits of the integer. This means that ~ inverts every bit, including leading zeros, turning a positive number into a negative one due to the two’s complement representation in Java.

Let’s verify the results using a JUnit 5 test and AssertJ matchers:

@Test
void givenPositiveInteger_whenFlipAllBits_thenReturnsNegativeComplement() {
    assertThat(flipAllBits(21)).isEqualTo(-22);
    assertThat(flipAllBits(0)).isEqualTo(-1);
    assertThat(flipAllBits(-1)).isEqualTo(0);
}

As we can see, flipping all 32 bits of 21 gives us -22, not 10. This is because Java’s int type is a signed 32-bit integer.

To get a result like 10 from 21, we need to flip only the significant bits. Let’s cover this case next.

4. Flipping Only the Significant Bits

In many practical scenarios, we want to flip only the bits that are actually used in the binary representation of the number, excluding leading zeros. For instance, flipping the significant bits of 21 (10101) should give us 10 (01010).

4.1. Using a Mask With Bit Length Calculation

The idea is straightforward: we create a mask with a 1 at each significant bit position, then XOR the number with this mask. The XOR operation flips only the bits where the mask has a 1:

public static int flipSignificantBits(int n) {
    if (n == 0) {
        return 0;
    }
    int bitLength = Integer.SIZE - Integer.numberOfLeadingZeros(n);
    int mask = (1 << bitLength) - 1;
    return n ^ mask;
}

First, we handle the edge case where n is 0. Then, we calculate the number of significant bits using Integer.numberOfLeadingZeros(). With this value, we create a mask by shifting 1 left by bitLength positions and subtracting 1, which gives us a sequence of 1s matching the significant bit length.

Finally, the XOR operation (^) flips only the significant bits, since XOR with 1 inverts a bit while XOR with 0 leaves it unchanged.

Let’s verify this with a test:

@Test
void givenPositiveInteger_whenFlipSignificantBits_thenReturnsFlippedValue() {
    assertThat(flipSignificantBits(21)).isEqualTo(10);
    assertThat(flipSignificantBits(26)).isEqualTo(5);
    assertThat(flipSignificantBits(0)).isEqualTo(0);
    assertThat(flipSignificantBits(1)).isEqualTo(0);
    assertThat(flipSignificantBits(7)).isEqualTo(0);
}

To illustrate, let’s trace through the example with 26 (binary 11010):

n     = 11010  (26)
mask  = 11111  (31)
n ^ mask = 00101  (5)

This approach effectively and efficiently flips only the significant bits.

4.2. Using Integer.highestOneBit()

We can also use the built-in Integer.highestOneBit() method to build the mask. This method returns a value with only the highest bit of the input set:

public static int flipSignificantBitsUsingHighestOneBit(int n) {
    if (n == 0) {
        return 0;
    }
    int mask = (Integer.highestOneBit(n) << 1) - 1;
    return n ^ mask;
}

Here, Integer.highestOneBit(n) returns the value of the most significant bit. By shifting it left by one position and subtracting 1, we create a mask with a 1 at each significant bit. Then, a XOR operation with this mask again flips only those bits.

4.3. Using the Bitwise NOT With a Mask

Instead of XOR, we can also combine the bitwise NOT operator with a mask to get the same result:

public static int flipSignificantBitsUsingNot(int n) {
    if (n == 0) {
        return 0;
    }
    int bitLength = Integer.SIZE - Integer.numberOfLeadingZeros(n);
    int mask = (1 << bitLength) - 1;
    return ~n & mask;
}

This function first computes the bitwise NOT of n, which flips all 32 bits. Then, the AND operation with the mask zeroes out all the bits beyond the significant ones. Simply put, the result is equivalent to flipping only the significant bits.

5. Alternative Methods

Apart from the standard bitwise operators, there are other, more unorthodox ways to flip all 32 bits of an integer.

5.1. Using Arithmetic Negation

Due to the two’s complement representation, flipping all bits of n is equivalent to computing -n – 1:

public static int flipBitsArithmetic(int n) {
    return -n - 1;
}

This works because, in two’s complement, the negation of n is the bitwise complement plus 1 (-n = ~n + 1). Therefore, ~n = -n – 1, which gives the same result as the bitwise NOT operator.

5.2. Using XOR With -1

Another way to flip all bits is to XOR the number with -1. In binary, we represent -1 as all 1s (11111111…1 in 32 bits). Notably, ~0 also evaluates to -1, so we can use either interchangeably:

public static int flipBitsXorMinusOne(int n) {
    return n ^ -1;
}

Since XOR with 1 flips a bit, performing XOR with a value where all bits are 1 effectively flips every bit in the integer. This produces the same result as the ~ operator.

6. Conclusion

In this article, we explored several approaches for flipping bits of an integer in Java. We started with the bitwise NOT operator for full 32-bit flipping. Next, we looked at mask-based methods for flipping only the significant bits using XOR and AND operations. Finally, we covered alternative approaches using arithmetic negation and XOR.

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

       

1. Overview

Authentication is the first line of defense in all web applications. Traditionally, applications rely on a username and password to verify a user’s identity. However, experts no longer consider relying on a single authentication factor secure for modern systems.

Multi-Factor Authentication (MFA) addresses this by requiring users to verify their identity using multiple independent factors before accessing a system.

Spring Security 7 introduces built-in support for multi-factor authentication, allowing developers to enforce multiple authentication steps using the existing authorization model. In this article, we’ll explore how MFA works in Spring Security 7 and how to implement it in a Spring Boot application.

2. Understanding MFA in Spring Security 7

Spring Security 7 introduces a new way to model authentication factors using authorities. Instead of treating MFA as a separate authentication mechanism, Spring Security progressively grants authorities for each successful authentication factor.

Multi-Factor Authentication (MFA) strengthens security by requiring users to verify their identity using multiple independent factors. These factors typically fall into three categories: something the user knows, such as a password or PIN, something the user has, such as a mobile device or email token, and something the user is, such as a fingerprint or other biometric data. By combining these factors, applications significantly reduce the risk of compromised credentials and unauthorized access.

Each time a user successfully authenticates with a specific factor, Spring Security adds a corresponding authority to the authentication object. This authority represents the factor that has already been verified during the authentication process. Some common examples include FACTOR_PASSWORD for password-based authentication, FACTOR_X509 for certificate-based authentication, and FACTOR_OTT for one-time token authentication. These authorities are represented internally by the FactorGrantedAuthority class and become part of the authenticated user’s security context.

This design allows authorization rules to verify that the required authentication factors are satisfied before granting access to protected resources.

3. Project Setup

Before implementing multi-factor authentication, we’ll set up a simple Spring Boot application using Spring Initializr with Spring Security 7. First, we need to configure the required dependencies.

We include Spring Boot starters for web, security, starter-test, webmvc-test, and security-testing:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>4.0.3</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
    <version>4.0.3</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <version>4.0.3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webmvc-test</artifactId>
    <version>4.0.3</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-test</artifactId>
    <version>7.0.0</version>
    <scope>test</scope>
</dependency>

This configuration adds the core dependencies required for our application. It includes Spring Boot’s web support for building REST endpoints, the Spring Security framework for implementing authentication and authorization, and Spring Security testing utilities for writing security-focused unit tests.

With these dependencies in place, the application now has everything required to configure and enable multi-factor authentication.

4. Enabling Multi-Factor Authentication Globally

Spring Security 7 introduces a convenient annotation called @EnableMultiFactorAuthentication. This annotation allows developers to define which authentication factors are required for all protected endpoints.

The following configuration enables MFA globally using password and X509 authentication factors:

@Configuration
@EnableWebSecurity
@EnableMultiFactorAuthentication(
  authorities = { FactorGrantedAuthority.PASSWORD_AUTHORITY, FactorGrantedAuthority.X509_AUTHORITY }
)
public class GlobalMfaSecurityConfig {
    @Bean
    @Order(3)
    SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
        http.securityMatcher("/**").authorizeHttpRequests(auth ->auth.requestMatchers("/public")
          .permitAll().anyRequest().authenticated()).formLogin(withDefaults());
        return http.build();
    }
}

This configuration enables Spring Security for the application and enables multi-factor authentication globally. As part of the setup, it specifies that the user must complete two authentication factors before the system considers them fully authenticated.

In this case, the required factors are password and X.509 certificate authentication. Once the configuration is active, every secured endpoint in the application requires both factors for access to be granted. Applying MFA globally like this helps avoid inconsistencies and reduces the risk of missing MFA rules in individual authorization configurations.

5. Applying MFA to Specific Endpoints

In many applications, MFA should be required only for sensitive endpoints, such as account settings, financial operations, or admin actions. Spring Security provides the AuthorizationManagerFactory API to define MFA rules programmatically.

The following configuration requires MFA only for admin endpoints:

@Configuration
@EnableWebSecurity
public class AdminMfaSecurityConfig {
    @Bean
    @Order(1)
    SecurityFilterChain adminSecurityFilterChain(HttpSecurity http) throws Exception {
        AuthorizationManagerFactory<Object> mfa = AuthorizationManagerFactories.multiFactor()
          .requireFactors(
            FactorGrantedAuthority.PASSWORD_AUTHORITY,
            FactorGrantedAuthority.X509_AUTHORITY)
          .build();
        http.securityMatcher("/admin/**").authorizeHttpRequests(auth ->auth.requestMatchers("/admin/**")
          .access(mfa.hasRole("ADMIN")).anyRequest().authenticated()).formLogin(withDefaults());
        return http.build();
    }
}

In this configuration, multi-factor authentication is applied only to requests that match the /admin/** endpoints. When a user attempts to access these routes, Spring Security checks whether the required authentication factors are present.

In addition to completing both authentication factors, the user must also have the ADMIN role. This approach provides fine-grained control over security rules, allowing developers to enforce MFA only on sensitive endpoints while keeping the rest of the application accessible with standard authentication.

6. Implementing Time-Based Authentication Rules

Some applications require users to re-authenticate before performing sensitive actions. For example, a banking application may require a fresh login before updating payment information. Spring Security 7 supports time-based MFA rules.

The following configuration requires the user to authenticate the password factor within the last five minutes:

@Configuration
@EnableWebSecurity
public class TimeBasedMfaSecurityConfig {
    @Bean
    @Order(2)
    SecurityFilterChain profileSecurityFilterChain(HttpSecurity http) throws Exception {
        AuthorizationManagerFactory<Object> recentLogin = AuthorizationManagerFactories.
          multiFactor().requireFactor(
            factor -> factor.passwordAuthority().validDuration(Duration.ofMinutes(5)))
          .build();
        http.securityMatcher("/profile", "/profile/**").authorizeHttpRequests(
          auth -> auth.requestMatchers("/profile", "/profile/**")
            .access(recentLogin.authenticated())
            .anyRequest().
            authenticated()).formLogin(withDefaults());
        return http.build();
    }
}

This rule allows users to navigate most parts of the application using their existing authenticated session. However, when a user attempts to access endpoints under */profile/**, the system verifies whether the password authentication was completed recently.

If the password factor is older than five minutes, Spring Security requires the user to authenticate again before granting access. This approach commonly allows users to perform sensitive operations, ensuring they complete critical actions only after a recent, verified authentication step.

7. Implementing User-Based MFA Rules

Sometimes MFA rules apply only to specific users. For example, administrators may be required to use MFA while regular users can log in with a single factor. Spring Security allows implementing custom authorization managers to support such scenarios.

The following example enforces MFA only for the admin user:

@Component
public class AdminMfaAuthorizationManager implements AuthorizationManager<Object> {
    AuthorizationManager<Object> mfa =
      AllAuthoritiesAuthorizationManager.hasAllAuthorities(FactorGrantedAuthority.OTT_AUTHORITY,
        FactorGrantedAuthority.PASSWORD_AUTHORITY);
    @Override
    public AuthorizationResult authorize(Supplier<? extends Authentication> authentication, Object context) {
        Authentication auth = authentication.get();
        if (auth != null && "admin".equals(auth.getName())) {
            return mfa.authorize(authentication, context);
        }
        return new AuthorizationDecision(true);
    }
}

This logic checks the authenticated user’s identity and applies MFA rules conditionally. If the authenticated user is an admin, the system verifies that the user has completed both required authentication factors before granting access.

For all other users, the system allows the request without enforcing additional MFA checks. This approach is useful when introducing MFA gradually, allowing organizations to enforce stronger security for high-privilege users first before extending it to the entire user base.

8. Writing Unit Tests for MFA

Testing authentication flows is essential to ensure that security rules behave as expected. Without proper tests, it becomes difficult to verify whether authentication requirements such as roles, permissions, or MFA factors are correctly enforced.

Spring Security provides dedicated testing utilities that make it easier to simulate authenticated users and validate authorization behavior. These tools allow developers to write focused tests that verify that security configurations function correctly without requiring a full authentication setup.

8.1. Controller Example

Before writing tests, we define a simple controller that exposes the endpoints secured by our MFA configurations:

@RestController
public class DemoController {
    @GetMapping("/public")
    public String publicEndpoint() {
        return "public endpoint";
    }
    @GetMapping("/profile")
    public String profileEndpoint() {
        return "profile endpoint";
    }
    @GetMapping("/admin/dashboard")
    public String adminDashboard() {
        return "admin dashboard";
    }
}

This controller exposes three endpoints /public, /profile, and /admin/dashboard that help demonstrate different MFA enforcement strategies.

8.2. MFA Security Test

This test verifies how the system behaves when it enforces multi-factor authentication globally:

@SpringBootTest(classes = Application.class)
@AutoConfigureMockMvc
class GlobalMfaSecurityTest {
    @Autowired
    MockMvc mockMvc;
    @Test
    void givenUserWithoutMfa_whenAccessProfile_thenForbidden() throws Exception {
        mockMvc.perform(get("/profile").with(user("user").roles("USER")))
          .andExpect(status().is3xxRedirection())
          .andExpect(header().string("Location", containsString("/login")));
    }
}

This test simulates a user attempting to access the admin endpoint without completing the required MFA factors. Since the authentication request only contains the basic role and does not include the necessary factor authorities, the request does not satisfy the configured security rules. As a result, Spring Security returns a 403 Forbidden response because the user has not completed all required authentication factors.

8.3. Admin Endpoint MFA Test

Next, we’ll verify that the system enforces MFA for admin endpoints:

@SpringBootTest(classes = Application.class)
@AutoConfigureMockMvc
class AdminMfaSecurityTest {
    @Autowired
    MockMvc mockMvc;
    @Test
    void givenAdminWithoutMfa_whenAccessAdminEndpoint_thenForbidden() throws Exception {
        mockMvc.perform(get("/admin/dashboard").with(user("admin").roles("ADMIN")))
          .andExpect(status().is3xxRedirection())
          .andExpect(header().string("Location", containsString("/login")));
    }
}

This test simulates an administrator attempting to access the /admin/dashboard endpoint. Although the user has the required ADMIN role, the request does not include the required MFA authorities. Because the authentication factors are incomplete, Spring Security redirects the request to the login page. This confirms that MFA enforcement works correctly for privileged endpoints.

8.4. Time-Based MFA Security Test

Some operations require users to authenticate recently to ensure no one has compromised the session. The following test verifies that the profile endpoint requires a recent authentication:

@SpringBootTest(classes = Application.class)
@AutoConfigureMockMvc
class TimeBasedMfaSecurityTest {
    @Autowired
    MockMvc mockMvc;
    @Test
    void givenUserWithoutRecentAuthentication_whenAccessProfile_thenForbidden() throws Exception {
        mockMvc.perform(get("/profile").with(user("user").roles("USER")))
          .andExpect(status().is3xxRedirection())
          .andExpect(header().string("Location", containsString("/login")));
    }
}

This test checks that the /profile endpoint requires a recent authentication. Since the simulated request does not include the necessary MFA factor information, Spring Security redirects the request to the login page. This confirms that the system correctly enforces the time-based MFA rule.

9. Conclusion

Multi-Factor Authentication (MFA) is a critical security measure for modern applications, helping reduce the risk of unauthorized access by requiring multiple verification factors.

Spring Security 7 provides built-in support for MFA, allowing developers to enforce multiple authentication steps using the existing authorization model. In this article, we explored how FactorGrantedAuthority models MFA, how to enable it globally with @EnableMultiFactorAuthentication, and how to apply it selectively to specific endpoints using AuthorizationManagerFactory. We also covered time-based rules, custom user-based policies, and testing MFA behavior using Spring Security test utilities.

By leveraging these features, developers can build secure and flexible authentication flows. As security threats continue to evolve, implementing MFA is no longer optional but an essential step in protecting user data and critical systems. As always, the code for this example is available over on GitHub.