Baeldung

Java List Series

baeldung — Thu, 30 Apr 2026 07:50:21 +0000

The List interface is one of Java’s most essential collection types, offering ordered, index-based access to elements with flexible implementations including ArrayList and LinkedList. Understanding how to create, search, sort, and transform lists is a core skill for any Java developer.

This series covers practical List operations from the ground up, organized by task: from picking the right implementation and initializing lists efficiently, through modifying elements, iterating and sorting, finding and filtering, and converting between collection types.

List Types and Fundamentals

Creating and Initializing Lists

Adding, Removing, and Modifying Elements

Iterating and Sorting Lists

Searching and Filtering Lists

Converting Lists

The post Java List Series first appeared on Baeldung.

Store Java Objects in HttpSession

Sourov Jajodia — Thu, 30 Apr 2026 00:07:54 +0000

1. Introduction

When developing Java-based web applications, there are many situations where we need to maintain user-related data between HTTP requests. HTTP is a stateless protocol and does not maintain any information between requests. This means that each HTTP request is independent and has no prior knowledge of the other requests made for the same session.

In this tutorial, we’ll discuss the basic concepts related to the HttpSession interface in detail. We’ll also discuss the process of storing, retrieving, and deleting Java objects using the key methods provided by the interface, such as setAttribute(), getAttribute(), and removeAttribute().

2. What is HttpSession?

The HttpSession interface is a part of the javax.servlet.http package. It’s used to store a user’s data on the server side between multiple HTTP requests. HTTP is a stateless protocol. HttpSession fills the gap between HTTP’s statelessness and the need to store a user’s data on the server side by providing a unique session to each user.

The servlet container manages the creation of sessions and tracks them using a unique session ID stored as a cookie named JSESSIONID in the client’s browser. We can access a session from any servlet using the getSession() method of the HttpServletRequest object. Let’s see an example of obtaining a session:

HttpSession session = request.getSession();

The request.getSession() method will return the existing active session if one has already been created. Otherwise, it’ll create a brand new one. We can also send the value false as a parameter: request.getSession(false). This allows us to get the existing session without creating a new one. Once we have the session object, we’re ready to start storing data in it.

3. Storing a Java Object in HttpSession

The Java object is stored within a session by means of a setAttribute() method provided by an HttpSession interface. The method takes two parameters: a String key and an object to be stored. This makes it easy to associate any Java object with a key for later retrieval.

Let’s say we have a User class and we want to store a logged-in user’s data in the session. First, here’s our simple User class:

public class User implements Serializable {
    private String username;
    private String email;
    public User(String username, String email) {
        this.username = username;
        this.email = email;
    }
    public String getUsername() { return username; }
    public String getEmail() { return email; }
}

Now, here’s how we store an instance of this object in the session inside a servlet:

protected void doPost(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException {
    User user = new User("john_doe", "john@example.com");
    HttpSession session = request.getSession();
    session.setAttribute("loggedInUser", user);
}

In this example, we first create a new User object with a username and email. Then, we call request.getSession() to obtain the current session. After that, we use session.setAttribute(“loggedInUser”, user) to store the object under the key “loggedInUser”. From this point on, any servlet or JSP in the same session can access this object using that exact key.

4. Retrieving a Java Object from HttpSession

Once we have stored an object in the session, we need a reliable mechanism to access it in the next request. The getAttribute() function provides exactly that purpose. It returns the corresponding object given a key used in the setAttribute() function. And so, it enables us to access the user’s data throughout the entire session.

Building on our previous example, here’s how we retrieve the stored User object in another servlet:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException {
    HttpSession session = request.getSession(false);
    private static final Logger logger = LoggerFactory.getLogger(StoreSessionServlet.class);
    if (session != null) {
        User user = (User) session.getAttribute("loggedInUser");
        if (user != null) {
            logger.info("Welcome back, " + user.getUsername());
        } else {
            logger.info("No user found in session.");
        }
    } else {
        logger.info("No active session found.");
    }
}

First, we begin with a call to request.getSession(false) to obtain the current session without accidentally opening a new session. Then, we retrieve the stored object via session.getAttribute(“loggedInUser”), casting it to User. The key point is to always check that it is not null. For example, a session has timed out, or maybe we haven’t yet set the attribute. So, a simple null check is a common pattern to keep our code safe from potential NullPointerException issues.

5. Removing an Object from HttpSession

At some point, we’ll have to clean up the session data that’s no longer required. For example, we clear the user’s details when the user logs out or clear a specific attribute. The HttpSession interface provides two ways of doing it: removeAttribute(), which removes a specific object, and invalidate(), which clears the session.

Here’s how we use both in practice:

protected void doPost(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException {
    HttpSession session = request.getSession(false);
    if (session != null) {
        session.removeAttribute("loggedInUser");
        session.invalidate();
    }
}

In this example, we begin by retrieving the existing session through request.getSession(false). Then, we remove the existing User object we previously stored by calling session.removeAttribute(“loggedInUser”), leaving all other session data intact. session.invalidate() removes the entire session, clearing all the data contained within the session from memory. Moreover, it is important to include a null check to avoid errors when there is no active session.

6. Conclusion

In this article, we’ve discussed how to manage Java objects within an HttpSession using three basic operations: setAttribute to put objects into the session, getAttribute to retrieve objects from the session, and removeAttribute to clean up specific objects from the session. As you can see, we have good control over objects stored within a session and can use this to build stateful, user-aware web applications using the stateless HTTP protocol.

Beyond the basics, we also saw why careful session handling matters. We perform null checks when retrieving attributes and call invalidate() on logout to prevent stale data from lingering on the server. With these fundamentals in place, we’re able to tackle real-world session management challenges and build Java web applications that are both robust and secure.

As always, the full code is available over on Github.

The post Store Java Objects in HttpSession first appeared on Baeldung.

Algorithms in Java Series

baeldung — Wed, 29 Apr 2026 17:40:01 +0000

Algorithms are at the heart of software development, providing foundational solutions to recurring computational problems. From classic sorting routines and graph traversal to advanced optimization and concurrency patterns, a strong grasp of algorithms enables Java developers to write code that is both efficient and correct.

This curated series covers the most important algorithms implemented in Java, organized by topic to guide you from core sorting and searching techniques through graph theory, mathematical computation, string processing, and systems design.

Sorting and Searching

Graph and Tree Algorithms

Array and String Algorithms

Mathematical Algorithms

Optimization and AI Algorithms

Concurrency and Systems Algorithms

The post Algorithms in Java Series first appeared on Baeldung.

Spring AI Series

baeldung — Wed, 29 Apr 2026 08:43:50 +0000

Spring AI is a comprehensive framework for building AI-powered applications on the Spring platform, providing abstractions over language model providers. It enables Java developers to integrate conversational AI, retrieval-augmented generation, and agentic workflows into their applications using familiar Spring patterns.

This curated series provides a practical guide to building AI applications with Spring AI, from core chat and memory concepts to advanced patterns like RAG pipelines, custom advisors, AI agents, and Model Context Protocol (MCP) integration.

Getting Started with Spring AI

AI Models and Providers

RAG and Vector Stores

Advisors and AI Agents

Model Context Protocol (MCP)

Multimodal and Advanced Capabilities

The post Spring AI Series first appeared on Baeldung.

AI in Java Series

baeldung — Wed, 29 Apr 2026 06:59:57 +0000

Artificial intelligence has become a core concern for Java developers, with a growing ecosystem of frameworks and tools for building everything from simple chatbots to sophisticated agentic systems. Java offers strong support for modern AI development through frameworks like Spring AI and LangChain4j, as well as direct integrations with the major LLM providers.

This curated series provides a practical guide to building AI-powered applications in Java, covering foundational concepts, Spring AI’s core features, retrieval-augmented generation, the Model Context Protocol, AI agents, and deep learning libraries.

Getting Started with AI in Java

Building with Spring AI

RAG and Vector Search

Model Context Protocol (MCP)

AI Agents

Deep Learning and ML Libraries

The post AI in Java Series first appeared on Baeldung.

A Guide to @NamedEntityGraph in Hibernate

Amar Wadhwani — Sat, 25 Apr 2026 21:46:41 +0000

1. Overview

JPA provides entity graphs to give us control over entity fetch plans at runtime. However, defining those graphs becomes verbose quickly with deeper association hierarchies.

Hibernate 7 introduces an enhanced Hibernate-specific @NamedEntityGraph annotation (org.hibernate.annotations.NamedEntityGraph) that enables defining entity graphs using a text-based graph language. Instead of nested annotation trees, we define the entity graphs using strings.

In this tutorial, we’ll explore the @NamedEntityGraph annotation, including a few examples of how it works.

2. Setup

Before diving into the usage, let’s prepare the proper environment.

2.1. Hibernate ORM

To use the new annotation, we need the Hibernate ORM dependency (version 7.0 or later):


    org.hibernate.orm
    hibernate-core
    7.3.1.Final
    compile

Next, we set the data model.

2.2. Data Model

Here, we use the blog domain model from the JPA tutorial.

Let’s start with the User entity:

@Entity
@Table(name = "app_user")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;
    // standard getters and setters
}

The User entity serves as the base class in a single-table inheritance hierarchy.

Next, let’s define an Author, which represents a User who writes posts:

@Entity
public class Author extends User {
    private String bio;
    // standard getters and setters
}

Similarly, we define a Moderator, which represents a User who manages the site:

@Entity
public class Moderator extends User {
    private String department;
    // standard getters and setters
}

Next, we define the Post entity, which has a @ManyToOne association to User and a @OneToMany association to Comment:

@Entity
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String subject;
    
    @OneToMany(mappedBy = "post")
    private List comments = new ArrayList<>();
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn
    private User user;
    // standard getters and setters
}

Finally, the Comment entity references both the Post it belongs to and the User who wrote it:

@Entity
public class Comment {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String reply;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn
    private Post post;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn
    private User user;
    // standard getters and setters
}

At this point, we are ready to explore @NamedEntityGraph in practice.

3. Text-Based Graph Language

Hibernate enables the creation of entity graphs by parsing a textual representation of a comma-separated list of attributes and subgraph specifications.

The grammar is fairly straightforward and can be summarized in three points:

simple attributes are comma-separated
subgraphs are enclosed in parentheses
nested subgraphs are supported

Here, we use this syntax to define the named graphs more concisely.

4. Understanding @NamedEntityGraph

Hibernate offers the @NamedEntityGraph annotation as an alternative to the JPA one, and accepts a graph attribute containing a text representation of a fetch plan.

4.1. Simple Graph

To fetch, we list the attributes we want using parentheses for subgraphs:

@NamedEntityGraph(graph = "subject, user, comments(user)")
@Entity
public class Post {
    // ....
}

Compared to the JPA approach, this is a clear and concise way to define the entity graph, which fetches the subject, user, and comments, and for each comment, also fetches its user. Under the hood, Hibernate parses the graph definition and builds the same Entity Graph structure that the JPA annotation tree would produce.

4.2. Defining Multiple Graphs

Hibernate registers the graph using the entity name by default. However, we can also name a graph to distinguish it from the others using the name attribute:

@NamedEntityGraph(name = "post-with-comment-users", graph = "subject, user, comments(user)")
@Entity
public class Post {
    // ...
}

Furthermore, we can use the @NamedEntityGraph annotation to define multiple entity graphs on the same entity:

@NamedEntityGraph(name = "post-basic", graph = "subject, user, comments")
@NamedEntityGraph(name = "post-with-comment-users", graph = "subject, user, comments(user)")
@NamedEntityGraph(name = "post-with-typed-users", graph = "subject, user(name),
    user(Author: bio), user(Moderator: department)")
@Entity
public class Post {
    // ...
}

Based on the definitions above, we can now use post-basic to fetch only comments without their users, while a detailed page can use post-with-comment-users to load the full comment tree.

Of course, we can also place the annotation at the package level using the package-info.java file. However, the graph string must be prefixed with the entity name:

@org.hibernate.annotations.NamedEntityGraph(name = "package-post-with-comment-users", graph = "Post: subject, user, comments(user)")
package com.baeldung.hibernate.entitygraph.model;

This way, Hibernate can infer which entity the graph belongs to.

4.3. Subtype-Specific Subgraphs

The text syntax also supports targeting specific subtypes in an inheritance hierarchy. A Post references a User, and Hibernate determines the concrete type at runtime.

To that end, we can target each subtype by prefixing the attributes with the subtype name:

@NamedEntityGraph(name = "post-with-typed-user", graph = "subject, user(name), user(Author: bio), user(Moderator: department)")
@Entity
public class Post {
    // ...
}

This graph definition tells Hibernate that the User name is to be fetched in all cases, and if it’s an Author, fetch its bio, or if it’s a Moderator, then fetch the department.

4.4. Map Key Subgraphs

If the attribute is a Map and the map’s key is itself a managed entity, we can define a subgraph for the key by appending .key to the attribute name.

For example, if the Post entity had a Map attribute called commentsByUser, we can fetch the user name along with the map entry:

@org.hibernate.annotations.NamedEntityGraph(graph = "commentsByUser.key(name)")

Without the .key, the subgraph would apply to the map value type, which is Comment in this case.

5. Using the GraphParser

Hibernate also exposes GraphParser, which enables graph creation at runtime. The parse(), method accepts an entity class, the graph string, and EntityManager:

final EntityGraph graph = GraphParser
    .parse(Post.class, "subject, user, comments(user)", entityManager);

We can also enrich an existing graph or subgraph at runtime using the parseInto() method:

EntityGraph graph = GraphParser.createEntityGraph(Post.class);
GraphParser.parseInto(graph, "subject, user", entityManger);
GraphParser.parseInto(graph, "comments(user)", entityManger);

Thus, we ensure proper typing.

6. Merging Graphs

Different aspects of the graph may be defined at multiple parts of an application. Hibernate enables us to combine multiple entity graphs into a single graph, which is the union of all the graphs using the merge() method:

EntityGraph mergedGraph = EntityGraphs.merge(entityManager, Post.class,
    entityManager.getEntityGraph("post-basic"),
    entityManager.getEntityGraph("post-with-comment-users"));

The merged graph fetches everything from both graphs into a single query; we could’ve used the graph string approach as well with the same effect.

7. Using the Graphs

Once an entity graph has been defined, either at runtime or via an annotation, it needs to be applied to an actual query. There are two possible approaches: one is via the plain JPA EntityManager, as we saw in the JPA tutorial, and the other option is to use Spring Data JPA.

7.1. Using EntityManager

The standard JPA approach uses hints, where we pass a Map, with either jakarta.persistence.fetchgraph or jakarta.persistence.loadgraph as the key and the EntityGraph object as the value:

EntityGraph graph = entityManager.getEntityGraph("post-with-comment-users");
        
Map hints = Map.of("jakarta.persistence.fetchgraph", graph);
        
Post post = entityManager.find(Post.class, 1L, hints);

The hint key determines the behaviour; using fetchgraph or loadgraph determines what is loaded.

Importantly, we can apply the same hint either to EntityManager.find() or to a JPQL query.

7.2. Using Spring Data JPA

Critically, we can skip the hints while using Spring Data JPA. The @EntityGraph annotation handles the wiring internally once we reference the graph by name on a repository method. In addition, we can set the type explicitly:

public interface PostRepository extends JpaRepository {
    @EntityGraph(value = "post-basic", type = EntityGraph.EntityGraphType.LOAD)
    List findAll(String subject);
    @EntityGraph(value = "post-with-comment-users")
    Post findBySubject(String subject);
}

Otherwise, Hibernate treats the graphs as fetchgraph by default.

8. Testing

Let’s explore a few scenarios to verify how these entity graphs work in practice.

8.1. Using a Named Graph

Let’s start with a simple named entity graph post-with-comment-users and apply it using fetchgraph:

@Test
void whenFindWithFetchGraph_thenAssociationsAreLoaded() {
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    EntityGraph graph = (EntityGraph) entityManager.getEntityGraph("post-with-comment-users");
    Post post = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "First Post")
        .setHint("jakarta.persistence.fetchgraph", graph)
        .getSingleResult();
    entityManager.close();
    assertNotNull(post);
    assertEquals("First Post", post.getSubject());
    assertTrue(Hibernate.isInitialized(post.getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments()));
    assertEquals(2, post.getComments().size());
    assertTrue(Hibernate.isInitialized(post.getComments().get(0).getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments().get(1).getUser()));
}

Here, we verify that the named entity graph fetches Post and all its associations, including the commenting User.

8.2. Using EntityManager.find()

On the other hand, we can also apply the same named graph using EntityManager.find():

@Test
void whenFindingByIdWithEntityManagerHints_thenAssociationsAreLoaded() {
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    Long postId = entityManager.createQuery("Select p.id from Post p where p.subject = :subject", Long.class)
        .setParameter("subject", "First Post")
        .getSingleResult();
    EntityGraph graph = (EntityGraph) entityManager.getEntityGraph("post-with-comment-users");
    Post post = entityManager.find(Post.class, postId, Map.of("jakarta.persistence.fetchgraph", graph));
    entityManager.close();
    assertNotNull(post);
    assertEquals("First Post", post.getSubject());
    assertTrue(Hibernate.isInitialized(post.getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments()));
    assertEquals(2, post.getComments().size());
    assertTrue(Hibernate.isInitialized(post.getComments().get(0).getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments().get(1).getUser()));
}

This shows that the same graph can be applied using JPA hints outside a JPQL query as well.

8.3. Comparing Multiple Graphs

Let’s take a look at how multiple named entity graphs defined on the entity work.

In this case, we use the post-basic named entity graph and compare it with the post-with-comments-user one:

@Test
void whenUsingPostBasicGraph_thenCommentUsersRemainLazy() {
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    EntityGraph graph = (EntityGraph) entityManager.getEntityGraph("post-basic");
    Post post = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "First Post")
        .setHint("jakarta.persistence.fetchgraph", graph)
        .getSingleResult();
    entityManager.close();
    assertNotNull(post);
    assertEquals("First Post", post.getSubject());
    assertTrue(Hibernate.isInitialized(post.getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments()));
    assertFalse(Hibernate.isInitialized(post.getComments().get(0).getUser()));
}

As we can see, the Post and all associations are loaded similarly to the previous example; however, the User for the Comments is lazy.

8.4. Subtype-Specific Subgraphs

Next, we verify how to fetch the subtype-specific subgraphs.

Specifically, we defined the post-with-typed-user graph:

@Test
void whenUsingTypedUserGraph_thenSubtypeAttributesAreLoaded() {
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    EntityGraph graph = (EntityGraph) entityManager.getEntityGraph("post-with-typed-user");
    Post authorPost = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "First Post")
        .setHint("jakarta.persistence.fetchgraph", graph)
        .getSingleResult();
    Post moderatorPost = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "Second Post")
        .setHint("jakarta.persistence.fetchgraph", graph)
        .getSingleResult();
    entityManager.close();
    assertNotNull(authorPost);
    assertTrue(Hibernate.isInitialized(authorPost.getUser()));
    assertEquals("Author 1", authorPost.getUser().getName());
    assertInstanceOf(Author.class, authorPost.getUser());
    assertTrue(Hibernate.isPropertyInitialized(authorPost.getUser(), "bio"));
    assertEquals("A Baeldung Author", ((Author) authorPost.getUser()).getBio());
    assertNotNull(moderatorPost);
    assertTrue(Hibernate.isInitialized(moderatorPost.getUser()));
    assertEquals("Moderator 1", moderatorPost.getUser().getName());
    assertInstanceOf(Moderator.class, moderatorPost.getUser());
    assertTrue(Hibernate.isPropertyInitialized(moderatorPost.getUser(), "department"));
    assertEquals("A Baeldung Moderator", ((Moderator) moderatorPost.getUser()).getDepartment());
}

This code should fetch the name for all User types and the bio if it’s an Author or the department if it’s a Moderator instance.

8.5. Parsing Graphs at Runtime

Hibernate also enables us to build graphs at runtime.

When using the parse() method, we can create a new graph:

@Test
void whenParsingGraphsAtRuntime_thenAssociationsAreLoaded() {
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    EntityGraph parsedGraph = GraphParser.parse(Post.class, "subject, user, comments(user)", entityManager);
    EntityGraph parsedIntoGraph = entityManager.createEntityGraph(Post.class);
    GraphParser.parseInto(parsedIntoGraph, "subject, user", entityManager);
    GraphParser.parseInto(parsedIntoGraph, "comments(user)", entityManager);
    Post parsedPost = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "First Post")
        .setHint("jakarta.persistence.fetchgraph", parsedGraph)
        .getSingleResult();
    Post parsedIntoPost = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "First Post")
        .setHint("jakarta.persistence.fetchgraph", parsedIntoGraph)
        .getSingleResult();
    entityManager.close();
    assertNotNull(parsedPost);
    assertEquals("First Post", parsedPost.getSubject());
    assertTrue(Hibernate.isInitialized(parsedPost.getUser()));
    assertTrue(Hibernate.isInitialized(parsedPost.getComments()));
    assertEquals(2, parsedPost.getComments().size());
    assertTrue(Hibernate.isInitialized(parsedPost.getComments().get(0).getUser()));
    assertTrue(Hibernate.isInitialized(parsedPost.getComments().get(1).getUser()));
    assertNotNull(parsedIntoPost);
    assertEquals("First Post", parsedIntoPost.getSubject());
    assertTrue(Hibernate.isInitialized(parsedIntoPost.getUser()));
    assertTrue(Hibernate.isInitialized(parsedIntoPost.getComments()));
    assertEquals(2, parsedIntoPost.getComments().size());
    assertTrue(Hibernate.isInitialized(parsedIntoPost.getComments().get(0).getUser()));
    assertTrue(Hibernate.isInitialized(parsedIntoPost.getComments().get(1).getUser()));
}

Notably, we can enrich an existing graph with the parseInto() method.

8.6. Merging Graphs

Finally, we can merge multiple graphs into a single graph:

@Test
void whenMergingGraphs_thenUnionOfAttributesIsLoaded() {
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    EntityGraph basicGraph = (EntityGraph) entityManager.getEntityGraph("post-basic");
    EntityGraph postWithCommentUsersGraph = (EntityGraph) entityManager.getEntityGraph("post-with-comment-users");
    EntityGraph mergedGraph = EntityGraphs.merge(entityManager, Post.class,
        basicGraph,
        postWithCommentUsersGraph);
    Post post = entityManager.createQuery("Select p from Post p where p.subject = :subject", Post.class)
        .setParameter("subject", "First Post")
        .setHint("jakarta.persistence.fetchgraph", mergedGraph)
        .getSingleResult();
    entityManager.close();
    assertNotNull(post);
    assertEquals("First Post", post.getSubject());
    assertTrue(Hibernate.isInitialized(post.getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments()));
    assertEquals(2, post.getComments().size());
    assertTrue(Hibernate.isInitialized(post.getComments().get(0).getUser()));
    assertTrue(Hibernate.isInitialized(post.getComments().get(1).getUser()));
}

Thus, we get the union of all the merged graphs.

9. Conclusion

In this article, we explored the @NamedEntityGraph annotation of Hibernate as well as the text-based graph language behind it.

First, we started with simple attribute lists, exploring nested subgraphs and subtype-specific subgraphs. Next, we looked into the GraphParser, which enables parsing graphs at runtime, and the EntityGraph merging of multiple graphs. Finally, we compared how simple, clear, and concise the Hibernate version is as compared to the JPA version.

As always, the code is available over on GitHub.

The post A Guide to @NamedEntityGraph in Hibernate first appeared on Baeldung.

Java Weekly, Issue 643

baeldung — Thu, 23 Apr 2026 19:26:11 +0000

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.

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]

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

Importing p7b File to Java Keystore Using Keytool in Java

Vishal Shanbhag — Wed, 22 Apr 2026 05:02:48 +0000

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


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.
The post Importing p7b File to Java Keystore Using Keytool in Java first appeared on Baeldung.



Introduction to Spring Data AOT Repositories
Stelios Anastasakis — Wed, 22 Apr 2026 04:19:23 +0000
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:

    org.springframework.boot
    spring-boot-starter-web
    4.0.5


    org.springframework.boot
    spring-boot-starter-data-jpa
    4.0.5

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 save(User user);
    @Transactional(readOnly = true)
    List findAll();
    List findAllById(Iterable longs);
    @Query(value = "SELECT * FROM users", nativeQuery = true)
    List nativeQueryFindAllUsers();
    @Query(value = "SELECT u FROM User u")
    List 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:

Spring finds the Repository interfaces
Passes them to the JpaRepositoryFactory
The JpaRepositoryFactory builds the SimpleJpaRepository instances
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 nativeQueryFindAllUsers() {
        String var1 = "SELECT * FROM users";
        Query var2 = this.entityManager.createNativeQuery(var1, User.class);
        return var2.getResultList();
    }
    public List 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.
The post Introduction to Spring Data AOT Repositories first appeared on Baeldung.
       


Convert IPv4 to IPv6 Address in Java
Ali Imran Nagori — Wed, 22 Apr 2026 04:14:40 +0000
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.
The post Convert IPv4 to IPv6 Address in Java first appeared on Baeldung.
       


Java Weekly, Issue 642
baeldung — Fri, 17 Apr 2026 10:45:25 +0000
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]
The post Java Weekly, Issue 642 first appeared on Baeldung.
       


Resolving PatternSyntaxException: Unclosed character class
Neetika Khandelwal — Thu, 16 Apr 2026 03:30:58 +0000
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.
The post Resolving PatternSyntaxException: Unclosed character class first appeared on Baeldung.