1. Overview

int result = 0b1100 & 0b0111;
assertEquals(0b0100, result);

int result = 0b1100 | 0b0111;
assertEquals(0b1111, result);

int result = 0b1100 ^ 0b0111;
assertEquals(0b1011, result);

int result = ~0b0101;
assertEquals(-0b0110, result);

int result = 0b0101 << 2;
assertEquals(0b10100, result);

int result = 0b0101 >> 1;
assertEquals(0b10, result);

int originalColor = 0xFF336699;
int alphaMask = 0xFF000000;
int redMask = 0x00FF0000;
int greenMask = 0x0000FF00;
int blueMask = 0x000000FF;

3.2. Extracting Color Components

int alpha = (originalColor & alphaMask) >>> 24;
int red = (originalColor & redMask) >>> 16;
int green = (originalColor & greenMask) >>> 8;
int blue = originalColor & blueMask;

red = Math.min(255, red + 50);
green = Math.min(255, green + 30);

int modifiedColor = (alpha << 24) | (red << 16) | (green << 8) | blue;

       

1. Overview

Querydsl and JPA Criteria are popular frameworks for constructing type-safe queries in Java. They both provide ways to express queries statically typed, making it easier to write efficient and maintainable code for interacting with databases. In this article, we’ll compare them from various perspectives.

2. Setup

First, we need to set up dependencies and configurations for our tests. In all the examples, we’ll use HyperSQL Database:

<dependency>
    <groupId>org.hsqldb</groupId>
    <artifactId>hsqldb</artifactId>
    <version>2.7.1</version>
</dependency>

We’ll use JPAMetaModelEntityProcessor and JPAAnnotationProcessor to generate metadata for our frameworks. For this purpose, we’ll add maven-processor-plugin with the following configuration:

<plugin>
    <groupId>org.bsc.maven</groupId>
    <artifactId>maven-processor-plugin</artifactId>
    <version>5.0</version>
    <executions>
        <execution>
            <id>process</id>
            <goals>
                <goal>process</goal>
            </goals>
            <phase>generate-sources</phase>
            <configuration>
                <processors>
                    <processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
                    <processor>com.querydsl.apt.jpa.JPAAnnotationProcessor</processor>
                </processors>
            </configuration>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-jpamodelgen</artifactId>
            <version>6.2.0.Final</version>
        </dependency>
    </dependencies>
</plugin>

Then, let’s configure properties for our EntityManager:

<persistence-unit name="com.baeldung.querydsl.intro">
    <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
    <properties>
        <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>
        <property name="hibernate.connection.url" value="jdbc:hsqldb:mem:test"/>
        <property name="hibernate.connection.username" value="sa"/>
        <property name="hibernate.connection.password" value=""/>
        <property name="hibernate.hbm2ddl.auto" value="update"/>
        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
    </properties>
</persistence-unit>

2.1. JPA Criteria

To use the EntityManager, we need to specify dependencies for any JPA provider. Let’s choose a Hibernate as the most popular one:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>6.2.0.Final</version>
</dependency>

To support code generation functionality, we’ll add the Annotation Processor dependency:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-jpamodelgen</artifactId>
    <version>6.2.0.Final</version>
</dependency>

2.2. Querydsl

Since we’re going to use it with the EntityManager, we still need to include the dependency from the previous section. Additionally, we’ll incorporate Querydsl dependency:

<dependency>
    <groupId>com.querydsl</groupId>
    <artifactId>querydsl-jpa</artifactId>
    <version>5.0.0</version>
</dependency>

To support code generation functionality, we’ll add APT based Source code generation dependency:

<dependency>
    <groupId>com.querydsl</groupId>
    <artifactId>querydsl-apt</artifactId>
    <classifier>jakarta</classifier>
    <version>5.0.0</version>
</dependency>

3. Simple Queries

Let’s start with the simple queries to one entity without any additional logic. We’ll use the next data model, the root entity will be a UserGroup:

@Entity
public class UserGroup {
    @Id
    @GeneratedValue
    private Long id;
    private String name;
    @ManyToMany(cascade = CascadeType.PERSIST)
    private Set<GroupUser> groupUsers = new HashSet<>();
    // getters and setters
}

In this entity, we’ll establish a many-to-many relationship with a GroupUser:

@Entity
public class GroupUser {
    @Id
    @GeneratedValue
    private Long id;
    private String login;
    @ManyToMany(mappedBy = "groupUsers", cascade = CascadeType.PERSIST)
    private Set<UserGroup> userGroups = new HashSet<>();
    @OneToMany(cascade = CascadeType.PERSIST, mappedBy = "groupUser")
    private Set<Task> tasks = new HashSet<>(0);
 
    // getters and setters
}

And, finally, we’ll add a Task entity that relates many-to-one to our User:

@Entity
public class Task {
    @Id
    @GeneratedValue
    private Long id;
    private String description;
    @ManyToOne
    private GroupUser groupUser;
    // getters and setters
}

3.1. JPA Criteria

Now, let’s select all the UserGroup items from the database:

@Test
void givenJpaCriteria_whenGetAllTheUserGroups_thenExpectedNumberOfItemsShouldBePresent() {
    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaQuery<UserGroup> cr = cb.createQuery(UserGroup.class);
    Root<UserGroup> root = cr.from(UserGroup.class);
    CriteriaQuery<UserGroup> select = cr.select(root);
    TypedQuery<UserGroup> query = em.createQuery(select);
    List<UserGroup> results = query.getResultList();
    Assertions.assertEquals(3, results.size());
}

We created an instance of CriteriaBuilder by calling the getCriteriaBuilder() method of EntityManager. Then, we created an instance of CriteriaQuery for our UserGroup model. After that, we obtained an instance of TypedQuery by calling the EntityManager createQuery() method. By calling the getResultList() method, we retrieved the list of entities from the database. As we can see, the expected number of items is present in the result collection.

3.2. Querydsl

Let’s prepare the JPAQueryFactory instance, which we’ll use to create our queries.

@BeforeEach
void setUp() {
    em = emf.createEntityManager();
    em.getTransaction().begin();
    queryFactory = new JPAQueryFactory(em);
}

Now, we’ll perform the same query as in the previous section using Querydsl:

@Test
void givenQueryDSL_whenGetAllTheUserGroups_thenExpectedNumberOfItemsShouldBePresent() {
    List<UserGroup> results = queryFactory.selectFrom(QUserGroup.userGroup).fetch();
    Assertions.assertEquals(3, results.size());
}

Using the selectFrom() method of the JPAQueryFactory starts building a query for our entity. Then, fetch() retrieves the values from the database into the persistence context. Finally, we’ve achieved the same result, but our query-building process is significantly shorter.

4. Filtering, Ordering and Grouping

Let’s delve into a more complex example. We’ll explore how our frameworks handle filtering, sorting, and data aggregation queries.

4.1. JPA Criteria

In this example, we’ll query all the UserGroup entities filtering them using names, which should be in one of two lists. The result we’ll sort by UserGroup name in descending order. Additionally, we’ll aggregate unique IDs per each UserGroup from the result:

@Test
void givenJpaCriteria_whenGetTheUserGroups_thenExpectedAggregatedDataShouldBePresent() {
    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaQuery<Object[]> cr = cb.createQuery(Object[].class);
    Root<UserGroup> root = cr.from(UserGroup.class);
    CriteriaQuery<Object[]> select = cr
      .multiselect(root.get(UserGroup_.name), cb.countDistinct(root.get(UserGroup_.id)))
      .where(cb.or(
        root.get(UserGroup_.name).in("Group 1", "Group 2"),
        root.get(UserGroup_.name).in("Group 4", "Group 5")
      ))
      .orderBy(cb.desc(root.get(UserGroup_.name)))
      .groupBy(root.get(UserGroup_.name));
    TypedQuery<Object[]> query = em.createQuery(select);
    List<Object[]> results = query.getResultList();
    assertEquals(2, results.size());
    assertEquals("Group 2", results.get(0)[0]);
    assertEquals(1L, results.get(0)[1]);
    assertEquals("Group 1", results.get(1)[0]);
    assertEquals(1L, results.get(1)[1]);
}

All the base methods here are the same as in the previous JPA Criteria section. Instead of selectFrom(), in this example, we use multiselect(), where we specify all the items that will be returned. We use the second parameter of this method for the aggregated amount of UserGroup IDs. In the where() method, we added filters we’ll apply to our query.

Then we call the orderBy() method, specifying the ordering field and type. Finally, in the groupBy() method, we specify a field that will be our key for aggregated data.

As we can see, a few UserGroup items were returned. They’re placed in the expected order and the result also contains aggregated data.

4.2. Querydsl

Now, let’s make the same query using Querydsl:

@Test
void givenQueryDSL_whenGetTheUserGroups_thenExpectedAggregatedDataShouldBePresent() {
    List<Tuple> results = queryFactory
      .select(userGroup.name, userGroup.id.countDistinct())
      .from(userGroup)
      .where(userGroup.name.in("Group 1", "Group 2")
        .or(userGroup.name.in("Group 4", "Group 5")))
      .orderBy(userGroup.name.desc())
      .groupBy(userGroup.name)
      .fetch();
    assertEquals(2, results.size());
    assertEquals("Group 2", results.get(0).get(userGroup.name));
    assertEquals(1L, results.get(0).get(userGroup.id.countDistinct()));
    assertEquals("Group 1", results.get(1).get(userGroup.name));
    assertEquals(1L, results.get(1).get(userGroup.id.countDistinct()));
}

Aiming for grouping functionality, we’ve replaced the selectFrom() method with two separate methods. In the select() method, we’ve specified the group field and aggregated function. In the from() method, we instruct the query builder on which entity should be applied. Similar to JPA Criteria, where(), orderBy(), and groupBy() are used to describe the filtering, ordering, and fields for grouping.

Finally, we achieved the same result with a slightly more compact syntax.

5. Complex Queries With JOINs

In this example, we’ll create complex queries that join all our entities. The result will contain a list of UserGroup entities with all their related entities.

Let’s prepare some data for our tests:

Stream.of("Group 1", "Group 2", "Group 3")
  .forEach(g -> {
      UserGroup userGroup = new UserGroup();
      userGroup.setName(g);
      em.persist(userGroup);
      IntStream.range(0, 10)
        .forEach(u -> {
            GroupUser groupUser = new GroupUser();
            groupUser.setLogin("User" + u);
            groupUser.getUserGroups().add(userGroup);
            em.persist(groupUser);
            userGroup.getGroupUsers().add(groupUser);
            IntStream.range(0, 10000)
              .forEach(t -> {
                  Task task = new Task();
                  task.setDescription(groupUser.getLogin() + " task #" + t);
                  task.setUser(groupUser);
                  em.persist(task);
              });
        });
      em.merge(userGroup);
  });

So, in our database, we’ll have three UserGroups, each containing ten GroupUsers. Each GroupUser will have ten thousand Tasks.

5.1. JPA Criteria

Now, let’s make a query using JPA CriteriaBuider:

@Test
void givenJpaCriteria_whenGetTheUserGroupsWithJoins_thenExpectedDataShouldBePresent() {
    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaQuery<UserGroup> query = cb.createQuery(UserGroup.class);
    query.from(UserGroup.class)
      .<UserGroup, GroupUser>join(GROUP_USERS, JoinType.LEFT)
      .join(tasks, JoinType.LEFT);
    List<UserGroup> result = em.createQuery(query).getResultList();
    assertUserGroups(result);
}

We use the join() method specifying the entity we want to join with and its type. After the execution, we retrieved a list of results. Let’s assert it using the following code:

private void assertUserGroups(List<UserGroup> userGroups) {
    assertEquals(3, userGroups.size());
    for (UserGroup group : userGroups) {
        assertEquals(10, group.getGroupUsers().size());
        for (GroupUser user : group.getGroupUsers()) {
            assertEquals(10000, user.getTasks().size());
        }
    }
}

As we can see, all the expected items were retrieved from the database.

5.2. Querydsl

Let’s achieve the same goal using Querydsl:

@Test
void givenQueryDSL_whenGetTheUserGroupsWithJoins_thenExpectedDataShouldBePresent() {
    List<UserGroup> result = queryFactory
      .selectFrom(userGroup)
      .leftJoin(userGroup.groupUsers, groupUser)
      .leftJoin(groupUser.tasks, task)
      .fetch();
    assertUserGroups(result);
}

Here, we use the leftJoin() method to add the connection to another entity. All the join types have separate methods. Both syntaxes are not very wordy. In the Querydsl implementation, our query is slightly more readable.

6. Modifying Data

Both frameworks support data modification. We can utilize it to update data based on complex and dynamic criteria. Let’s see how it works.

6.1. JPA Criteria

Let’s update UserGroup with a new name:

@Test
void givenJpaCriteria_whenModifyTheUserGroup_thenNameShouldBeUpdated() {
    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaUpdate<UserGroup> criteriaUpdate = cb.createCriteriaUpdate(UserGroup.class);
    Root<UserGroup> root = criteriaUpdate.from(UserGroup.class);
    criteriaUpdate.set(UserGroup_.name, "Group 1 Updated using Jpa Criteria");
    criteriaUpdate.where(cb.equal(root.get(UserGroup_.name), "Group 1"));
    em.createQuery(criteriaUpdate).executeUpdate();
    UserGroup foundGroup = em.find(UserGroup.class, 1L);
    assertEquals("Group 1 Updated using Jpa Criteria", foundGroup.getName());
}

To modify the data we use a CriteriaUpdate instance, which is used to create a Query. We set all the field names and values are going to be updated. Finally, we call the executeUpdate() method to run the update query. As we can see, we have a modified name field in the updated entity.

6.2. Querydsl

Now, let’s update UserGroup using Querydsl:

@Test
void givenQueryDSL_whenModifyTheUserGroup_thenNameShouldBeUpdated() {
    queryFactory.update(userGroup)
      .set(userGroup.name, "Group 1 Updated Using QueryDSL")
      .where(userGroup.name.eq("Group 1"))
      .execute();
    UserGroup foundGroup = em.find(UserGroup.class, 1L);
    assertEquals("Group 1 Updated Using QueryDSL", foundGroup.getName());
}

From queryFactory we create the update query by calling the update() method. Then, we set new values for the entity fields using the set() method. We’ve updated the name successfully. Similar to previous examples, Querydsl offers a slightly shorter and more declarative syntax.

7. Integration With Spring Data JPA

We can use Querydsl and JPA Criteria to implement dynamic filtering in our Spring Data JPA repositories. Let’s add Spring Data JPA starter dependency first:

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

7.1. JPA Criteria

Let’s create a Spring Data JPA repository for our UserGroup extending JpaSpecificationExecutor:

public interface UserGroupJpaSpecificationRepository 
  extends JpaRepository<UserGroup, Long>, JpaSpecificationExecutor<UserGroup> {
    default List<UserGroup> findAllWithNameInAnyList(List<String> names1, List<String> names2) {
        return findAll(specNameInAnyList(names1, names2));
    }
    default Specification<UserGroup> specNameInAnyList(List<String> names1, List<String> names2) {
        return (root, q, cb) -> cb.or(
          root.get(UserGroup_.name).in(names1),
          root.get(UserGroup_.name).in(names2)
        );
    }
}

In this repository, we’ve created a method that filters our results based on any of two name lists from the parameters. Let’s use it and see, how it works:

@Test
void givenJpaSpecificationRepository_whenGetTheUserGroups_thenExpectedDataShouldBePresent() {
    List<UserGroup> results = userGroupJpaSpecificationRepository.findAllWithNameInAnyList(
      List.of("Group 1", "Group 2"), List.of("Group 4", "Group 5"));
    assertEquals(2, results.size());
    assertEquals("Group 1", results.get(0).getName());
    assertEquals("Group 4", results.get(1).getName());
}

We can see that the result list contains exactly the expected groups.

7.2. Querydsl

The same functionality we can achieve using Querydsl Predicate. Let’s create another Spring Data JPA repository for the same entity:

public interface UserGroupQuerydslPredicateRepository 
  extends JpaRepository<UserGroup, Long>, QuerydslPredicateExecutor<UserGroup> {
    default List<UserGroup> findAllWithNameInAnyList(List<String> names1, List<String> names2) {
        return StreamSupport
          .stream(findAll(predicateInAnyList(names1, names2)).spliterator(), false)
          .collect(Collectors.toList());
    }
    default Predicate predicateInAnyList(List<String> names1, List<String> names2) {
        return new BooleanBuilder().and(QUserGroup.userGroup.name.in(names1))
          .or(QUserGroup.userGroup.name.in(names2));
    }
}

QuerydslPredicateExecutor provides only Iterable as the container for multiple results. If we want to use another type, we must handle the conversions ourselves. As we can see, the client code for this repository will be very similar to that for JPA specifications:

@Test
void givenQuerydslPredicateRepository_whenGetTheUserGroups_thenExpectedDataShouldBePresent() {
    List<UserGroup> results = userQuerydslPredicateRepository.findAllWithNameInAnyList(
      List.of("Group 1", "Group 2"), List.of("Group 4", "Group 5"));
    assertEquals(2, results.size());
    assertEquals("Group 1", results.get(0).getName());
    assertEquals("Group 4", results.get(1).getName());
}

8. Performance

Querydsl ultimately prepares the same criteria query but introduces additional conventions beforehand. Let’s measure how this process impacts the performance of our queries. To measure execution time, we can use our IDE functionality or create a timing extension.

We’ve executed all our test methods a few times and saved the median result into a list:

Method [givenJpaSpecificationRepository_whenGetTheUserGroups_thenExpectedDataShouldBePresent] took 128 ms.
Method [givenQuerydslPredicateRepository_whenGetTheUserGroups_thenExpectedDataShouldBePresent] took 27 ms.
Method [givenJpaCriteria_whenGetAllTheUserGroups_thenExpectedNumberOfItemsShouldBePresent] took 1 ms.
Method [givenQueryDSL_whenGetAllTheUserGroups_thenExpectedNumberOfItemsShouldBePresent] took 3 ms.
Method [givenJpaCriteria_whenModifyTheUserGroup_thenNameShouldBeUpdated] took 13 ms.
Method [givenQueryDSL_whenModifyTheUserGroup_thenNameShouldBeUpdated] took 161 ms.
Method [givenJpaCriteria_whenGetTheUserGroupsWithJoins_thenExpectedDataShouldBePresent] took 887 ms.
Method [givenQueryDSL_whenGetTheUserGroupsWithJoins_thenExpectedDataShouldBePresent] took 728 ms.
Method [givenJpaCriteria_whenGetTheUserGroups_thenExpectedAggregatedDataShouldBePresent] took 5 ms.
Method [givenQueryDSL_whenGetTheUserGroups_thenExpectedAggregatedDataShouldBePresent] took 88 ms.

As we can see, in most cases, we achieve similar execution times for both Querydsl and JPA Criteria. In the modification case, Querydsl uses JPQLSerializer and prepares a JPQL query string, which leads to additional overhead.

9. Conclusion

In this article, we’ve thoroughly compared JPA Criteria and Querydsl in various scenarios. In many cases, Querydsl emerged as the preferable option due to its slightly more user-friendly syntax. If a few more dependencies in the project are not an issue, we can consider it a good tool to improve our code readability. On the other hand, we can achieve all the functionality using JPA criteria.

As usual, the full source code can be found over on GitHub.

       

1. Overview

In today’s event-driven architectures, managing data streams effectively is essential. Apache Kafka is a popular choice for this, but integrating it into our applications has its challenges, despite helper frameworks such as Spring Kafka. One major challenge is implementing proper dynamic listener management, which provides flexibility and control that is crucial for adapting to our application’s changing workloads and maintenance.

In this tutorial, we’ll learn how to dynamically start and stop Kafka listeners in Spring Boot applications.

2. Prerequisites

First, let’s import the spring-kafka dependency into our project:

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
    <version>3.1.2</version>
</dependency>

3. Configuring the Kafka Consumer

Producers are applications that publish (write) events to Kafka topics.

Throughout this tutorial, we’ll use unit tests to simulate producers sending events to Kafka topics. Consumers, who subscribe to topics and process the stream of events, are represented by a listener within our application. This listener is configured to process incoming messages from Kafka.

Let’s configure our Kafka consumer through the KafkaConsumerConfig class, which includes the Kafka broker’s address, the consumer group ID, and the deserializers for the key and value:

@Bean
public DefaultKafkaConsumerFactory<String, UserEvent> consumerFactory() {
    Map<String, Object> props = new HashMap<>();
    props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
    props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
    props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, JsonDeserializer.class);
    props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
    props.put(JsonDeserializer.TRUSTED_PACKAGES, "com.baeldung.spring.kafka.start.stop.consumer");
    return new DefaultKafkaConsumerFactory<>(props, new StringDeserializer(), new JsonDeserializer<>(UserEvent.class));
}

4. Configuring the Kafka Listener

In Spring Kafka, annotating a method with @KafkaListener creates a listener that consumes messages from a specified topic. To define it, let’s declare a UserEventListener class:

@KafkaListener(id = Constants.LISTENER_ID, topics = Constants.MULTI_PARTITION_TOPIC, groupId = "test-group",
  containerFactory = "kafkaListenerContainerFactory", autoStartup = "false")
public void processUserEvent(UserEvent userEvent) {
    logger.info("Received UserEvent: " + userEvent.getUserEventId());
    userEventStore.addUserEvent(userEvent);
}

The above listener waits for messages from the topic multi_partition_topic and processes them using the processUserEvent() method. We assign the groupId as test-group, ensuring that the consumer becomes part of a broader group, thus facilitating distributed processing across multiple instances.

We assign each listener a unique identifier using the id attribute. In this example, the assigned listener ID is listener-id-1.

The autoStartup property gives us control over whether the listener is started when the application is initialized. In our example, we’ll set it to false, which means the listener does not start automatically when the application boots up. This configuration provides us with the flexibility to initiate the listener manually.

This manual initiation can be triggered by various events, such as a new user registration, a specific condition within the application, such as reaching a certain data volume threshold, or an administrative action, such as manually starting the listener via a management interface. For example, if an online retail application detects a surge in traffic during a flash sale, it could automatically start additional listeners to handle the increased load, optimizing performance.

The UserEventStore acts as a temporary storage for events received by the listener:

@Component
public class UserEventStore {
    private final List<UserEvent> userEvents = new ArrayList<>();
    public void addUserEvent(UserEvent userEvent) {
        userEvents.add(userEvent);
    }
    public List<UserEvent> getUserEvents() {
        return userEvents;
    }
    public void clearUserEvents() {
        this.userEvents.clear();
    }
}

5. Dynamically Controlling the Listener

Let’s create a KafkaListenerControlService that dynamically starts and stops Kafka listeners using KafkaListenerEndpointRegistry:

@Service
public class KafkaListenerControlService {
    @Autowired
    private KafkaListenerEndpointRegistry registry;
    public void startListener(String listenerId) {
        MessageListenerContainer listenerContainer = registry.getListenerContainer(listenerId);
        if (listenerContainer != null && !listenerContainer.isRunning()) {
            listenerContainer.start();
        }
    }
    public void stopListener(String listenerId) {
        MessageListenerContainer listenerContainer = registry.getListenerContainer(listenerId);
        if (listenerContainer != null && listenerContainer.isRunning()) {
            listenerContainer.stop();
        }
    }
}

The KafkaListenerControlService can precisely manage individual listener instances based on their assigned ID. Both startListener() and stopListener() methods use listenerId as a parameter, allowing us to start and stop message consumption from the topics as required.

KafkaListenerEndpointRegistry acts as a central repository for all Kafka listener endpoints defined within a Spring application context. It monitors these listener containers, thus permitting programmatic control over their state, be it starting, stopping, or pausing. This capability is essential for applications that need to adjust their message processing activities in real-time, without necessitating a restart of the entire application.

6. Validate Dynamic Listener Controls

Next, let’s focus on testing the dynamic start and stop capabilities of Kafka listeners within our Spring Boot application. First, let’s start the listener:

kafkaListenerControlService.startListener(Constants.LISTENER_ID);

We then verify that the listener is activated by sending and then processing a test event:

UserEvent startUserEventTest = new UserEvent(UUID.randomUUID().toString()); 
producer.send(new ProducerRecord<>(Constants.MULTI_PARTITION_TOPIC, startUserEventTest)); 
await().untilAsserted(() -> assertEquals(1, this.userEventStore.getUserEvents().size())); 
this.userEventStore.clearUserEvents();

Now that the listener is active, we’ll send a batch of ten messages for processing. After sending four messages, we’ll stop the listener and then send the remaining messages to the Kafka topic:

for (long count = 1; count <= 10; count++) {
    UserEvent userEvent = new UserEvent(UUID.randomUUID().toString());
    Future<RecordMetadata> future = producer.send(new ProducerRecord<>(Constants.MULTI_PARTITION_TOPIC, userEvent));
    RecordMetadata metadata = future.get();
    if (count == 4) {
        await().untilAsserted(() -> assertEquals(4, this.userEventStore.getUserEvents().size()));
        this.kafkaListenerControlService.stopListener(Constants.LISTENER_ID);
        this.userEventStore.clearUserEvents();
    }
    logger.info("User Event ID: " + userEvent.getUserEventId() + ", Partition : " + metadata.partition());
}

Before starting the listener, we’ll verify that there are no messages in the event store:

assertEquals(0, this.userEventStore.getUserEvents().size());
kafkaListenerControlService.startListener(Constants.LISTENER_ID);
await().untilAsserted(() -> assertEquals(6, this.userEventStore.getUserEvents().size()));
kafkaListenerControlService.stopListener(Constants.LISTENER_ID);

Once the listener starts again, it processes the remaining six messages that we sent to the Kafka topic after the listener was stopped. This test showcases the Spring Boot application’s ability to dynamically manage Kafka listeners.

7. Use Cases

Dynamic listener management excels in scenarios requiring high adaptability. For example, during peak load times, we can dynamically start additional listeners to enhance throughput and reduce processing time. Conversely, during maintenance or low-traffic periods, we can stop listeners to conserve resources. This flexibility is also beneficial for deploying new features behind feature flags, allowing seamless on-the-fly adjustments without impacting the overall system.

Let’s consider a scenario where an e-commerce platform introduces a new recommendation engine designed to enhance the user experience by suggesting products based on browsing history and purchase patterns. To verify this feature’s effectiveness before its full-scale launch, we decide to deploy it behind a feature flag.

Activating this feature flag starts the Kafka listener. As end users interact with the platform, the recommendation engine, powered by Kafka listeners, processes the incoming stream of user activity data to generate personalized product recommendations.

When we deactivate the feature flag, we stop the Kafka listener, and the platform defaults to its existing recommendation engine. This ensures a seamless user experience, regardless of the testing phase of the new engine.

While the feature is active, we actively collect data, monitor performance metrics, and make adjustments to the recommendation engine. We repeat this feature testing across multiple iterations until we achieve the desired results.

Through this iterative process, dynamic listener management proves to be a valuable tool. It allows for the seamless introduction of new features

8. Conclusion

In this article, we’ve addressed Kafka integration with Spring Boot, focusing on dynamically managing Kafka listeners. This capability is crucial for managing fluctuating workloads and performing routine maintenance. Additionally, it enables feature toggling, scales services based on traffic patterns, and manages event-driven workflows with specific triggers.

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

       

1. Introduction

When working with date and time data in Java applications, it’s often crucial to compare dates for various purposes, such as scheduling tasks, reminders, or reporting. One common scenario is the need to identify whether a given date corresponds to yesterday relative to the current date. In this tutorial, we’ll explore various approaches for determining whether a given date object falls on yesterday.

2. Using java.util.Calendar

One common approach is to use the java.util.Calendar classes to manipulate date and time information. To compare yesterday’s date, we instantiate a Calendar object via Calendar.getInstance(). Next, we set its time to the current date using calendar.setTime(new Date()), and then subtract one day using calendar.add(Calendar.DATE, -1). This yields yesterday’s date.

Here’s a code snippet demonstrating these concepts:

Date date = new Date(System.currentTimeMillis() - (1000 * 60 * 60 * 24));
Calendar expectedCalendar = Calendar.getInstance();
expectedCalendar.setTime(date);
Calendar actualCalendar = Calendar.getInstance();
actualCalendar.add(Calendar.DATE, -1);
boolean isEqualToYesterday = expectedCalendar.get(Calendar.YEAR) == actualCalendar.get(Calendar.YEAR) &&
  expectedCalendar.get(Calendar.MONTH) == actualCalendar.get(Calendar.MONTH) &&
  expectedCalendar.get(Calendar.DAY_OF_MONTH) == actualCalendar.get(Calendar.DAY_OF_MONTH);
assertTrue(isEqualToYesterday);

Directly comparing dates using this method may fail due to differences in milliseconds between the two dates. This is because the Date object captures both the date and time, including milliseconds. If the time component is not precisely the same, the comparison may yield incorrect results.

To mitigate this issue, one approach is to truncate the time component of both dates before performing the comparison. We extract the year, month, and day components from both the dates using their respective get(Calendar.YEAR), get(Calendar.MONTH), and get(Calendar.DAY_OF_MONTH) methods to solely determine whether the actualCalendar is equal to yesterday.

Although these classes are considered legacy APIs, they are still widely used, especially in environments where newer Java versions are not available.

3. Using java.util.Date Milliseconds

This approach leverages the fact that Date objects internally store milliseconds since the epoch (January 1, 1970, 00:00:00 UTC). It involves calculating yesterday’s midnight in milliseconds and comparing it with the getTime() value of the Date object.

We compute yesterday’s midnight in milliseconds using Instant.now().minus(1, ChronoUnit.DAYS).toEpochMilli(). This operation subtracts one day from the current instant and converts it to milliseconds since the epoch, effectively representing the timestamp for midnight of the previous day.

Subsequently, we compare this calculated value with the getTime() value of the given expectedDate. By verifying if expectedDate falls within the range from yesterday’s midnight timestamp to the next midnight (yesterdayMidnightMillis + 86_400_000 milliseconds), we ascertain whether yesterdayMidnightMillis corresponds to yesterday’s date.

Let’s demonstrate this approach with a quick example:

Date expectedDate = new Date(System.currentTimeMillis() - (1000 * 60 * 60 * 24));
long yesterdayMidnightMillis = Instant.now()
  .minus(1, ChronoUnit.DAYS)
  .toEpochMilli();
boolean isEqualToYesterday = expectedDate.getTime() >= yesterdayMidnightMillis && expectedDate.getTime() < yesterdayMidnightMillis + 86_400_000;
assertTrue(isEqualToYesterday);

This approach offers a simple and efficient method for comparing dates using milliseconds. It’s suitable for scenarios where direct comparison with legacy Date objects is required.

4. Using java.time.LocalDate 

Another approach to handling date manipulation is to use the LocalDate class along with its minusDays() method. This approach is part of the modern Date and Time API introduced in Java 8.

LocalDate offers a more straightforward and intuitive way to work with dates. It is designed to focus solely on the year, month, and day components, without a time component. This makes it ideal for date-only operations, such as recording historical dates or report date filtering.

To compare yesterday’s date using this method, we start by obtaining the current date using LocalDate.now(). Then, we simply call the minusDays(1) method on the LocalDate object to subtract one day, resulting in yesterday’s date:

Date date = new Date(System.currentTimeMillis() - (1000 * 60 * 60 * 24));
LocalDate expectedLocalDate = LocalDate.of(date.getYear() + 1900, date.getMonth() + 1, date.getDate());
LocalDate actualLocalDate = LocalDate.now().minusDays(1);
boolean isEqualToYesterday = expectedLocalDate.equals(actualLocalDate);
assertTrue(isEqualToYesterday);

In this example, we specify yesterday’s date by extracting the year, month, and day components from a Date object. However, note that the getYear() method returns the year since 1900, and getMonth() returns the month index starting from 0. Therefore, we add 1900 to getYear() and 1 to getMonth() to adjust them to the standard date representation.

Using LocalDate for date manipulation is recommended for Java versions 8 and above.

5. Using Joda-Time

Joda-Time is a popular date and time library for Java. We can use this library to check if a date object represents yesterday’s date. To compare yesterday’s date using Joda-Time, we utilize the DateTime class and its minusDays() method.

First, we obtain the current date and time using DateTime.now(). Then, we subtract one day from the current date by calling the minusDays(1) method, resulting in yesterday’s date:

Date date = new Date(System.currentTimeMillis() - (1000 * 60 * 60 * 24));
DateTime expectedDateTime = new DateTime(date).withTimeAtStartOfDay();
DateTime actualDateTime = DateTime.now().minusDays(1).withTimeAtStartOfDay();
boolean isEqualToYesterday = expectedDateTime.equals(actualDateTime);
assertTrue(isEqualToYesterday);

Similar to the Calendar class, Joda-Time’s DateTime class captures time along with the date, and thus, comparing them directly may lead to inaccuracies due to differences in milliseconds.

To resolve this, instead of breaking down the date value into year, month, and day components, we can leverage the withTimeAtStartOfDay() method provided by Joda-Time. This method sets the time component of a DateTime object to the start of the day, effectively resetting the time to midnight (00:00:00). By applying withTimeAtStartOfDay() to a DateTime object, we ensure that only the date component remains significant for comparison purposes.

6. Conclusion

In this article, we’ve explored a few approaches to determine whether a date object falls on yesterday’s date. For most modern Java applications using Java 8 or later, the LocalDate approach is generally recommended due to its clarity, immutability, and support for various date manipulations.

While Joda-Time is a mature and stable library, its future development and support may become less certain over time as more projects transition to the standard Java Date and Time API.

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

       

1. Overview

Caching data means our applications don’t have to access a slower storage layer, thereby improving their performance and responsiveness. We can implement caching using any in-memory implementation library like Caffeine.

Although doing this improves the performance of data retrieval, if the application is deployed to multiple replica sets, then the cache is not shared between instances. To overcome this problem, we can introduce a distributed cache layer that can be accessed by all instances.

In this article, we’ll learn how to implement the two-level caching mechanism in Spring. We’ll show how to implement both of these layers using Spring’s caching support, and how the distributed cache layer is called if the local cache layer incurs a cache miss.

2. Example Application in Spring Boot

Let’s imagine we need to build a simple application that calls a database to fetch some data.

2.1. Maven Dependency

First, let’s include the spring-boot-starter-web dependency:

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

2.2. Implementing a Spring Service

We’ll implement a Spring service that fetches the data from a repository.

First, let’s model the Customer class:

public class Customer implements Serializable {
    private String id;
    private String name;
    private String email;
    // standard getters and setters
}

Then, let’s implement the CustomerService class and a getCustomer method:

@Service
public class CustomerService {
    
    private final CustomerRepository customerRepository;
    public Customer getCustomer(String id) {
        return customerRepository.getCustomerById(id);
    }
}

Finally, let’s define the CustomerRepository interface:

public interface CustomerRepository extends CrudRepository<Customer, String> {
}

Next, let’s implement the two levels of caching.

3. Implement the First Level of Cache

We’ll leverage Spring’s cache support and the Caffeine library to implement the first cache layer.

3.1. Caffeine Dependencies

Let’s include the spring-boot-starter-cache and caffeine dependencies:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
    <version>3.1.5</version/
</dependency>
<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.8</version>
</dependency>

3.2. Enable Caffeine Cache

To enable the Caffeine cache, we’ll need to add a few cache-related configurations.

First, let’s add the @EnableCaching annotation in the CacheConfig class and include a few Caffeine cache configs:

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public CaffeineCache caffeineCacheConfig() {
        return new CaffeineCache("customerCache", Caffeine.newBuilder()
          .expireAfterWrite(Duration.ofMinutes(1))
          .initialCapacity(1)
          .maximumSize(2000)
          .build());
    }
}

Next, let’s add the CaffeineCacheManager bean using the SimpleCacheManager class and set the cache config:

@Bean
public CacheManager caffeineCacheManager(CaffeineCache caffeineCache) {
    SimpleCacheManager manager = new SimpleCacheManager();
    manager.setCaches(Arrays.asList(caffeineCache));
    return manager;
}

3.3. Include the @Cacheable Annotation

To enable the above caching, we’ll need to add @Cacheable annotation in the getCustomer method:

@Cacheable(cacheNames = "customerCache", cacheManager = "caffeineCacheManager")
public Customer getCustomer(String id) {
}

As discussed earlier, this works well in a single instance deployment environment but is not very effective when the application runs with multiple replicas.

4. Implement the Second Level of Cache

We’ll implement the second level of caching using the Redis server. Of course, we can implement it with any other distributed cache like Memcached. This layer of cache will be accessible to all of our application’s replicas.

4.1. Redis Dependency

Let’s add the spring-boot-starter-redis dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
    <version>3.1.5</version>
</dependency>

4.2. Enable Redis Cache

We’ll need to add the Redis cache-related configuration to enable it in the application.

First, let’s configure the RedisCacheConfiguration bean with a few properties:

@Bean
public RedisCacheConfiguration cacheConfiguration() {
    return RedisCacheConfiguration.defaultCacheConfig()
      .entryTtl(Duration.ofMinutes(5))
      .disableCachingNullValues()
      .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));
}

Then, let’s enable the CacheManager using the RedisCacheManager class:

@Bean
public CacheManager redisCacheManager(RedisConnectionFactory connectionFactory, RedisCacheConfiguration cacheConfiguration) {
    return RedisCacheManager.RedisCacheManagerBuilder
      .fromConnectionFactory(connectionFactory)
      .withCacheConfiguration("customerCache", cacheConfiguration)
      .build();
}

4.3. Include the @Caching and @Cacheable Annotations

We’ll include the second cache in the getCustomer method with the @Caching and @Cacheable annotations:

@Caching(cacheable = {
  @Cacheable(cacheNames = "customerCache", cacheManager = "caffeineCacheManager"),
  @Cacheable(cacheNames = "customerCache", cacheManager = "redisCacheManager")
})
public Customer getCustomer(String id) {
}

We should note that Spring will fetch the cache object from the first available cache. If both cache managers miss, it will run the actual method.

5. Implement the Integration Tests

To verify our setup, we’ll implement a few integration tests and validate both caches.

First, let’s create an integration test to verify both caches using an embedded Redis server:

@Test
void givenCustomerIsPresent_whenGetCustomerCalled_thenReturnCustomerAndCacheIt() {
    String CUSTOMER_ID = "100";
    Customer customer = new Customer(CUSTOMER_ID, "test", "test@mail.com");
    given(customerRepository.findById(CUSTOMER_ID))
      .willReturn(customer);
    
    Customer customerCacheMiss = customerService.getCustomer(CUSTOMER_ID);<code class="language-java">
    
    assertThat(customerCacheMiss).isEqualTo(customer);
    verify(customerRepository, times(1)).findById(CUSTOMER_ID);
    assertThat(caffeineCacheManager.getCache("customerCache").get(CUSTOMER_ID).get()).isEqualTo(customer);
    assertThat(redisCacheManager.getCache("customerCache").get(CUSTOMER_ID).get()).isEqualTo(customer);
}

We’ll run the above test case and find that this works fine.

Next, let’s imagine a scenario where the first level of cache data gets evicted due to expiry, and we try to get the same customer. Then, it should be a cache hit to the second cache level — Redis. Any further cache hit for the same customer should be to the first cache.

Let’s implement the above test scenario to check for both the caches after the local cache expiry:

@Test
void givenCustomerIsPresent_whenGetCustomerCalledTwiceAndFirstCacheExpired_thenReturnCustomerAndCacheIt() throws InterruptedException {
    String CUSTOMER_ID = "102";
    Customer customer = new Customer(CUSTOMER_ID, "test", "test@mail.com");
    given(customerRepository.findById(CUSTOMER_ID))
      .willReturn(customer);
    Customer customerCacheMiss = customerService.getCustomer(CUSTOMER_ID);
    TimeUnit.SECONDS.sleep(3);
    Customer customerCacheHit = customerService.getCustomer(CUSTOMER_ID);
    verify(customerRepository, times(1)).findById(CUSTOMER_ID);
    assertThat(customerCacheMiss).isEqualTo(customer);
    assertThat(customerCacheHit).isEqualTo(customer);
    assertThat(caffeineCacheManager.getCache("customerCache").get(CUSTOMER_ID).get()).isEqualTo(customer);
    assertThat(redisCacheManager.getCache("customerCache").get(CUSTOMER_ID).get()).isEqualTo(customer);
}

We now run the above test and see an unexpected assertion error with the Caffeine cache object:

org.opentest4j.AssertionFailedError: 
expected: Customer(id=102, name=test, email=test@mail.com)
but was: null
...
at com.baeldung.caching.twolevelcaching.CustomerServiceCachingIntegrationTest.
givenCustomerIsPresent_whenGetCustomerCalledTwiceAndFirstCacheExpired_thenReturnCustomerAndCacheIt(CustomerServiceCachingIntegrationTest.java:91)

From the above logs, it’s evident that the customer object is not in the Caffeine cache after the eviction, and even if we call the same method again, it’s not restored from the second cache. This is not an ideal situation for this use case, as every time the first level cache expires, it never gets updated until the second cache also expires. This puts additional load into the Redis cache.

We should note that Spring does not manage any data between multiple caches even if they are declared for the same method.

This tells us that we need to update the first-level cache whenever it’s accessed again.

6. Implement a Custom CacheInterceptor

To update the first cache, we’ll need to implement a custom cache interceptor to intercept whenever the cache is accessed.

We’ll add an interceptor to check if the current cache class is Redis type, and if the local cache does not exist, then we can update the cache value.

Let’s implement a custom CacheInterceptor by overriding the doGet method:

public class CustomerCacheInterceptor extends CacheInterceptor {
    private final CacheManager caffeineCacheManager;
    @Override
    protected Cache.ValueWrapper doGet(Cache cache, Object key) {
        Cache.ValueWrapper existingCacheValue = super.doGet(cache, key);
      
        if (existingCacheValue != null && cache.getClass() == RedisCache.class) {
            Cache caffeineCache = caffeineCacheManager.getCache(cache.getName());
            if (caffeineCache != null) {
                caffeineCache.putIfAbsent(key, existingCacheValue.get());
            }
        }
        return existingCacheValue;
    }
}

Also, we’ll need to register the CustomerCacheInterceptor bean to enable it:

@Bean
public CacheInterceptor cacheInterceptor(CacheManager caffeineCacheManager, CacheOperationSource cacheOperationSource) {
    CacheInterceptor interceptor = new CustomerCacheInterceptor(caffeineCacheManager);
    interceptor.setCacheOperationSources(cacheOperationSource);
    return interceptor;
}
@Bean
public CacheOperationSource cacheOperationSource() {
    return new AnnotationCacheOperationSource();
}

We should note that the custom interceptor will intercept the call whenever the Spring proxy method calls the get cache method internally.

We’ll re-run the integration tests, and see that the above test cases pass.

7. Conclusion

In this article, we’ve learned how to implement two levels of caching with Caffeine and Redis using Spring’s cache support. We’ve also seen how to update the first-level Caffeine cache with the custom cache interceptor implementation.

As always, the example code can be found over on GitHub.

       

1. Introduction

In Java, there are numerous ways to determine if a particular time lies within the two times without considering dates.

In this tutorial, we’ll look at several possible ways to achieve this.

2. Using the isAfter() and isBefore() Methods

Java 8 introduced the LocalTime class in the java.time package, providing convenient methods to work with time without considering the date:

LocalTime startTime = LocalTime.parse("09:00:00");
LocalTime endTime = LocalTime.parse("17:00:00");
LocalTime targetTime = LocalTime.parse("12:30:00");

Here, we initialize three LocalTime variables, startTime, endTime, and targetTime, with specific time values. These lines essentially set the starting time, ending time, and target time for comparison in the test methods.

LocalTime.parse(“09:00:00”) parses the string “09:00:00” into a LocalTime object representing 9:00 AM. Similarly, “17:00:00” represents 5:00 PM, and “12:30:00” represents 12:30 PM.

Let’s now test this approach:

@Test
void givenLocalTime_whenUsingIsAfterIsBefore_thenTimeIsBetween() {
    assertTrue(!targetTime.isBefore(startTime) && !targetTime.isAfter(endTime));
}

This method tests whether a given targetTime falls between a specified startTime and endTime using the isAfter() and isBefore() methods of the LocalTime class. We use the assetTrue() method to verify that the targetTime is neither before the startTime nor after the endTime.

3. Using the compareTo() Method

Another approach is to use the compareTo() method, which compares two LocalTime instances:

@Test
void givenLocalTime_whenUsingCompareTo_thenTimeIsBetween() {
    assertTrue(targetTime.compareTo(startTime) >= 0 && targetTime.compareTo(endTime) <= 0);
}

Here, the expression targetTime.compareTo(startTime) >= 0 && targetTime.compareTo(endTime) <= 0 combines two comparisons using logical AND (&&). It checks whether targetTime is greater than or equal to startTime and less than or equal to endTime.

This compound condition ensures that targetTime falls within the time range defined by startTime and endTime, inclusive. If both individual comparisons evaluate to true, the entire expression evaluates to true, indicating that the target time is between the start and end times, or coincides with them.

4. Using the after() and before() Methods

In this approach, we’ll use the legacy Date and Calendar objects to represent and compare times. Although this approach is considered less convenient than modern Java 8 LocalTime methods, it remains relevant for scenarios requiring compatibility with older codebases or systems:

@Test
void givenDate_whenUsingAfterBefore_thenTimeIsBetween() {
    Calendar startCalendar = Calendar.getInstance();
    startCalendar.set(Calendar.HOUR_OF_DAY, 9);
    startCalendar.set(Calendar.MINUTE, 0);
    Date startTime = startCalendar.getTime();
    Calendar endCalendar = Calendar.getInstance();
    endCalendar.set(Calendar.HOUR_OF_DAY, 17);
    endCalendar.set(Calendar.MINUTE, 0);
    Date endTime = endCalendar.getTime();
    Calendar targetCalendar = Calendar.getInstance();
    targetCalendar.set(Calendar.HOUR_OF_DAY, 12);
    targetCalendar.set(Calendar.MINUTE, 30);
    Date targetTime = targetCalendar.getTime();
    assertTrue(!targetTime.before(startTime) && !targetTime.after(endTime));
}

Firstly, we create Calendar instances for the startTime, endTime, and targetTime using the Calendar.getInstance() method, which returns a Calendar object initialized with the current date and time.

Once the Calendar objects are set up, we extract Date objects representing the start, end, and target times from their respective Calendar instances.

With the Date objects prepared, we compare the targetTime against the startTime and endTime. We achieve this by utilizing the Date class’s before() and after() methods.

5. Conclusion

In conclusion, Java offers multiple approaches, including modern LocalTime methods, legacy Date functionalities, and regular expressions, to accurately determine if a specific time falls within defined boundaries, catering to diverse development requirements.

As usual, the accompanying source code can be found over on GitHub.

       

1. Introduction

In this tutorial, we’ll explore two important Java classes for handling tasks that need to run concurrently: ExecutorService and CompletableFuture. We’ll learn their functionalities and how to use them effectively, and we’ll understand the key differences between them.

2. Overview of ExecutorService

The ExecutorService is a powerful interface in Java’s java.util.concurrent package that simplifies managing tasks that need to run concurrently. It abstracts away the complexities of thread creation, management, and scheduling, allowing us to focus on the actual work that needs to be done.

ExecutorService provides methods like submit() and execute() to submit tasks we want to run concurrently. These tasks are then queued and assigned to available threads within the thread pool. If the task returns results, we can use Future objects to retrieve them. However, retrieving results using methods like get() on a Future can block the calling thread until the task is completed.

3. Overview of CompletableFuture

The CompletableFuture was introduced in Java 8. It focuses on composing asynchronous operations and handling their eventual results in a more declarative way. A CompletableFuture acts as a container that holds the eventual result of an asynchronous operation. It might not have a result immediately, but it provides methods to define what to do when the result becomes available.

Unlike ExecutorService, where retrieving results can block the thread, CompletableFuture operates in a non-blocking manner.

4. Focus and Responsibilities

While both ExecutorService and CompletableFuture tackle asynchronous programming in Java, they serve distinct purposes. Let’s explore their respective focus and responsibilities.

4.1. ExecutorService

ExecutorService focuses on managing thread pools and executing tasks concurrently. It offers methods for creating thread pools with different configurations, such as fixed-size, cached, and scheduled.

Let’s see an example that creates and maintains exactly three threads using ExecutorService:

ExecutorService executor = Executors.newFixedThreadPool(3);
Future<Integer> future = executor.submit(() -> {
    // Task execution logic
    return 42;
});

The newFixedThreadPool(3) method call creates a thread pool with three threads, ensuring that no more than three tasks will be executed concurrently. The submit() method is then used to submit a task for execution in the thread pool, returning a Future object representing the result of the computation.

4.2. CompletableFuture

In contrast, CompletableFuture provides a higher-level abstraction for composing asynchronous operations. It focuses on defining the workflow and handling the eventual results of asynchronous tasks.

Here’s an example that uses supplyAsync() to initiate an asynchronous task that returns a string:

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> {
    return 42;
});

In this example, supplyAsync() initiates an asynchronous task that returns a result of 42.

5. Chaining Asynchronous Tasks

Both ExecutorService and CompletableFuture offer mechanisms for chaining asynchronous tasks, but they take different approaches.

5.1. ExecutorService

In ExecutorService, we typically submit tasks for execution and then use the Future objects returned by these tasks to handle dependencies and chain subsequent tasks. However, this involves blocking and waiting for the completion of each task before proceeding to the next, which can lead to inefficiencies in handling asynchronous workflows.

Consider the case where we submit two tasks to an ExecutorService and then chain them together using Future objects:

ExecutorService executor = Executors.newFixedThreadPool(2);
Future<Integer> firstTask = executor.submit(() -> {
    return 42;
});
Future<String> secondTask = executor.submit(() -> {
    try {
        Integer result = firstTask.get();
        return "Result based on Task 1: " + result;
    } catch (InterruptedException | ExecutionException e) {
        // Handle exception
    }
    return null;
});
executor.shutdown();

In this example, the second task depends on the result of the first task. However, ExecutorService doesn’t offer built-in chaining, so we need to explicitly manage the dependency by waiting for the first task to complete using get() — which blocks the thread — before submitting the second task.

5.2. CompletableFuture

On the other hand, CompletableFuture offers a more streamlined and expressive way to chain asynchronous tasks. It simplifies task chaining with built-in methods like thenApply(). These methods allow you to define a sequence of asynchronous tasks where the output of one task becomes the input for the next.

Here’s an equivalent example using CompletableFuture:

CompletableFuture<Integer> firstTask = CompletableFuture.supplyAsync(() -> {
    return 42;
});
CompletableFuture<String> secondTask = firstTask.thenApply(result -> {
    return "Result based on Task 1: " + result;
});

In this example, the thenApply() method is used to define the second task, which depends on the result of the first task. When we use thenApply() to chain a task to a CompletableFuture, the main thread doesn’t wait for the first task to complete before proceeding. It continues executing other parts of our code.

6. Error Handling

In this section, we’ll examine how both ExecutorService and CompletableFuture manage errors and exceptional scenarios.

6.1. ExecutorService

When using ExecutorService, errors can manifest in two ways:

• Exceptions thrown within the submitted tasks: These exceptions propagate back to the main thread when we attempt to retrieve the result using methods like get() on the returned Future object. This can lead to unexpected behavior if not handled appropriately.
• Unchecked exceptions during thread pool management: If an unchecked exception occurs during thread pool creation or shutdown, it’s typically thrown from the ExecutorService methods themselves. We need to catch and handle these exceptions in our code.

Let’s look at an example, highlighting the potential issues:

ExecutorService executor = Executors.newFixedThreadPool(2);
Future<String> future = executor.submit(() -> {
    if (someCondition) {
        throw new RuntimeException("Something went wrong!");
    }
    return "Success";
});
try {
    String result = future.get();
    System.out.println("Result: " + result);
} catch (InterruptedException | ExecutionException e) {
    // Handle exception
} finally {
    executor.shutdown();
}

In this example, the submitted task throws an exception if a specific condition is met. However, we need to use a try-catch block around future.get() to catch exceptions thrown by the task or during retrieval using get(). This approach can become tedious for managing errors across multiple tasks.

6.2. CompletableFuture

In contrast, CompletableFuture offers a more robust approach to error handling with methods like exceptionally() and handling exceptions within the chaining methods themselves. These methods allow us to define how to handle errors at different stages of the asynchronous workflow, without the need for explicit try-catch blocks.

Here’s an equivalent example using CompletableFuture with error handling:

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    if (someCondition) {
        throw new RuntimeException("Something went wrong!");
    }
    return "Success";
})
.exceptionally(ex -> {
    System.err.println("Error in task: " + ex.getMessage());
    return "Error occurred"; // Can optionally return a default value
});
future.thenAccept(result -> System.out.println("Result: " + result));

In this example, the asynchronous task throws an exception and the error is caught and handled within the exceptionally() callback. It provides a default value (“Error occurred”) in case of an exception.

7. Timeout Management

Timeout management is crucial in asynchronous programming to ensure that tasks are completed within a specified timeframe. Let’s explore how ExecutorService and CompletableFuture handle timeouts differently.

7.1. ExecutorService

ExecutorService doesn’t offer built-in timeout functionality. To implement timeouts, we need to work with Future objects and potentially interrupt tasks exceeding the deadline. This approach involves manual coordination:

ExecutorService executor = Executors.newFixedThreadPool(2);
Future<String> future = executor.submit(() -> {
    try {
        Thread.sleep(5000);
    } catch (InterruptedException e) {
        System.err.println("Error occured: " + e.getMessage());
    }
    return "Task completed";
});
try {
    String result = future.get(2, TimeUnit.SECONDS);
    System.out.println("Result: " + result);
} catch (TimeoutException e) {
    System.err.println("Task execution timed out!");
    future.cancel(true); // Manually interrupt the task.
} catch (Exception e) {
    // Handle exception
} finally {
    executor.shutdown();
}

In this example, we submit a task to the ExecutorService and specify a timeout of two seconds when retrieving the result using the get() method. If the task takes longer than the specified timeout to complete, a TimeoutException is thrown. This approach can be error-prone and requires careful handling.

It’s important to note that while the timeout mechanism interrupts the waiting for the task result, the task itself will continue running in the background until it either completes or is interrupted. For instance, to interrupt a task running within an ExecutorService, we need to use the Future.cancel(true) method.

7.2. CompletableFuture

In Java 9, CompletableFuture offers a more streamlined approach to timeouts with methods like completeOnTimeout(). The completeOnTimeout() method will complete the CompletableFuture with a specified value if the original task isn’t complete within the specified timeout duration.

Let’s look at an example that illustrates how completeOnTimeout() works:

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    try {
        Thread.sleep(5000);
    } catch (InterruptedException e) {
        // Handle exception
    }
    return "Task completed";
});
CompletableFuture<String> timeoutFuture = future.completeOnTimeout("Timed out!", 2, TimeUnit.SECONDS);
String result = timeoutFuture.join();
System.out.println("Result: " + result);

In this example, the supplyAsync() method initiates an asynchronous task that simulates a long-running operation, taking five seconds to complete. However, we specify a timeout of two seconds using completeOnTimeout(). If the task isn’t completed within two seconds, the CompletableFuture will be automatically completed with the value “Timed out!”.

8. Summary

Here’s the comparison table summarizing the key differences between ExecutorService and CompletableFuture:

9. Conclusion

In this article, we’ve explored two essential classes for handling asynchronous tasks: ExecutorService and CompletableFuture. ExecutorService simplifies the management of thread pools and concurrent task execution, while CompletableFuture provides a higher-level abstraction for composing asynchronous operations and handling their results.

We’ve also examined their functionalities, differences, and how they handle error handling, timeout management, and chaining of asynchronous tasks.

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

       

1. Introduction

Spring Data JPA provides a powerful abstraction layer for interacting with relational databases. However, traditional relational tables might not be ideal for storing complex, semi-structured data like product details or user preferences. This is where JSONB data types come in. In this tutorial, we’ll explore various approaches for querying JSONB columns using Spring Data JPA.

2. JSONB Columns

JSONB (JavaScript Object Notation for Databases) is a data type specifically designed for storing JSON data within relational databases like PostgreSQL. It allows us to represent complex data structures with key-value pairs and nested objects within a single column. In conjunction with the JPA provider (such as Hibernate), Spring Data JPA allows us to map these JSONB columns to attributes within our entity classes.

3. Mapping JSONB Columns

We can use the @Column annotation with the columnDefinition attribute to explicitly define the column type in the entity class:

@Column(columnDefinition = "jsonb")
private String attributes;

This approach is primarily relevant to PostgreSQL, which natively supports the jsonb data type. By adding this annotation to the corresponding attribute in our entity class, we provide a hint to the database about the desired column type. Spring Data JPA typically auto-detects the jsonb data type based on the database column definition, making this annotation optional in many cases.

4. Setting up Project Dependencies and Test Data

We’ll create a basic Spring Boot project with the necessary dependencies and test data for testing the JSONB queries.

4.1. Project Setup

First, we need to add the necessary dependencies to our Maven pom.xml file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <scope>runtime</scope>
</dependency>

4.2. Entity Class

Next, let’s create a Java class named Product to represent our entity:

public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    @Column(columnDefinition = "jsonb")
    private String attributes;
    // Getters and Setters 
}

This class defines the Product entity with id, name, and attributes fields. The attributes field is a String that will hold the serialized JSON data for product details. We use @Column(columnDefinition = “jsonb”) to hint the database to create an attributes column as a JSONB type.

After defining the Product entity class, Hibernate will generate the following SQL when the application starts up and initializes the database schema:

CREATE TABLE Product (
    id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    name VARCHAR(255),
    attributes JSONB
);

4.3. Prepare Test Data

Below is the SQL script that we use to prepare our database before running the test cases. We can save this script in a .sql file and place it inside the src/test/resources directory of our project:

DELETE FROM product;
INSERT INTO product (name, attributes)
VALUES ('Laptop', '{"color": "red", "size": "15 inch"}');
INSERT INTO product (name, attributes)
VALUES ('Phone', '{"color": "blue", "size": "6 inch"}');
INSERT INTO product (name, attributes)
VALUES ('Headphones', '{"brand": "Sony", "details": {"category": "electronics", "model": "WH-1000XM4"}}');
INSERT INTO product (name, attributes)
VALUES ('Laptop', '{"brand": "Dell", "details": {"category": "computers", "model": "XPS 13"}}');

Then, we use the @Sql annotation with the executionPhase attribute set to BEFORE_TEST_METHOD in the test class to insert test data into the database before each test method execution:

@Sql(scripts = "/testdata.sql", executionPhase = Sql.ExecutionPhase.BEFORE_TEST_METHOD)

5. Using Native Queries with @Query

In this section, we’ll leverage native SQL queries with PostgreSQL JSONB operators to filter and retrieve data based on values within the JSONB column. We use the @Query annotation to define these native queries within our Spring Data JPA repository interface.

5.1. Querying with JSONB Operators

The @Query annotation allows us to define custom queries within our repository interface using native SQL syntax. This approach is particularly useful when working with JSONB columns, as it enables us to utilize PostgreSQL’s native JSONB operators directly within the query.

Let’s write a query using JSONB operators to find all products with a specific color value:

public interface ProductRepository extends JpaRepository<Product, Long> {
    @Query(value = "SELECT * FROM product WHERE attributes ->> ?1 = ?2", nativeQuery = true)
    List<Product> findByAttribute(String key, String value);
}

The findByAttribute() method takes in two arguments representing the key of the JSON attribute (such as “color”) and filters by a value indicating the desired value for that attribute. The @Query annotation defines a native SQL query that utilizes the ->> operator to access the key within the attributes JSONB column.

Then, the placeholders ?1 and ?2 in the query are replaced with the actual name of the key and value provided as method arguments during execution. Next, let’s create a test case to verify the functionality of the findByAttribute() method:

List<Product> redProducts = productRepository.findByAttribute("color", "red");
assertEquals(1, redProducts.size());
assertEquals("Laptop", redProducts.get(0).getName());

5.2. Querying Nested with JSONB Operators

We’re utilizing PostgreSQL’s -> and ->> operators to query nested JSONB data:

• The -> operator is used to access a specific key within a JSONB object.
• The ->> operator is used to access the value corresponding to a specific key within a JSONB object as text.

Let’s write another query for handling nested keys:

@Query(value = "SELECT * FROM product WHERE attributes -> ?1 ->> ?2 = ?3", nativeQuery = true)
List<Product> findByNestedAttribute(String key1, String key2, String value);

This query allows us to search for entities where a specific nested attribute matches a given value. For example, if we want to find products where the “details.category” is “electronics”, we’d call this method with “details”, “category”, and “electronics“ as parameters:

List<Product> electronicProducts = productRepository.findByNestedAttribute("details", "category", "electronics");
assertEquals(1, electronicProducts.size());
assertEquals("Headphones", electronicProducts.get(0).getName());

5.3. Querying with jsonb_extract_path_text Functions

We can also leverage the jsonb_extract_path_text function in our native SQL queries to extract specific values from JSONB data. jsonb_extract_path_text is a PostgreSQL function used to extract a specific value from a JSONB column based on a given path.

The jsonb_extract_path_text function returns the extracted value as text. If the specified path doesn’t exist in the JSONB structure, the function returns NULL.

Let’s see an example of using jsonb_extract_path_text:

public interface ProductRepository extends JpaRepository<Product, Long> {
    @Query(value = "SELECT * FROM product WHERE jsonb_extract_path_text(attributes, ?1) = ?2", nativeQuery = true)
    List<Product> findByJsonPath(String path, String value);
}

The findByJsonPath() method accepts two arguments. The first argument is the path string indicating the specific key within the JSONB object to extract. The second argument represents the expected value for the extracted attribute:

List<Product> redProducts = productRepository.findByJsonPath("color", "red");
assertEquals(1, redProducts.size());
assertEquals("Laptop", redProducts.get(0).getName());

5.4. Querying Nested with jsonb_extract_path_text Functions

Let’s see how we can adjust the query to handle nested keys using jsonb_extract_path_text functions:

@Query(value = "SELECT * FROM product WHERE jsonb_extract_path_text(attributes, ?1, ?2) = ?3", nativeQuery = true)
List<Product> findByNestedJsonPath(String key1, String key2, String value);

We provide key1 and key2 as path elements to traverse the nested JSONB structure:

List<Product> electronicProducts = productService.findByNestedJsonPath("details", "category", "electronics");
assertEquals(1, electronicProducts.size());
assertEquals("Headphones", electronicProducts.get(0).getName());

In this example, the findByNestedJsonPath(“details”, “category”, “electronics”) would target products where the nested “details.category” value is “electronics“.

6. Using Custom JPA Specification Approach

JPA Specifications are interfaces that encapsulate the criteria used for filtering data. They define what data needs to be retrieved based on specific conditions. This interface, provided by Spring Data JPA, allows repositories to implement custom query methods that accept a Specification<T> instance as an argument.

We can create a class that implements the Specification<T> interface. This class defines the toPredicate() method, which utilizes the CriteriaBuilder to construct the actual query predicate based on the provided criteria (key and value for filtering):

public class ProductSpecification implements Specification<Product> {
    private final String key;
    private final String value;
    public ProductSpecification(String key, String value) {
        this.key = key;
        this.value = value;
    }
    @Override
    public Predicate toPredicate(Root root, CriteriaQuery<?> query, CriteriaBuilder cb) {
        return cb.equal(
            cb.function("jsonb_extract_path_text", String.class, root.get("attributes"), cb.literal(key)),
            value
        );
    }
}

The toPredicate() method defines how the filtering predicate is constructed using the CriteriaBuilder provided as an argument. In this example, we’re assuming the key is located at the top level of the JSONB data.

To use this custom specification, the ProductRepository needs to extend JpaSpecificationExecutor<Product>:

public interface ProductRepository extends JpaRepository<Product, Long>, JpaSpecificationExecutor<Product> {
}

Here’s a basic example of a custom specification for filtering products based on attributes within the JSONB column:

ProductSpecification spec = new ProductSpecification("color", "red");
Page<Product> redProducts = productRepository.findAll(spec, Pageable.unpaged());
assertEquals(1, redProducts.getContent().size());
assertEquals("Laptop", redProducts.getContent().get(0).getName());

7. Conclusion

In this article, we explored various approaches for querying JSONB columns using Spring Data JPA. For basic filtering criteria, native SQL queries might offer a straightforward solution. However, the JPA specification provides a compelling alternative when dealing with complex filtering logic or the need for reusability.

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

       

1. Introduction

A perfect number is a special type of positive integer that holds a unique property as it is equal to the sum of its proper divisors, excluding the number itself.

One of the most intriguing aspects of perfect numbers is their rarity. Perfect numbers are infrequent within the realm of integers. In fact, throughout history, only a handful of perfect numbers have been identified. The first four perfect numbers known to humanity are 6, 28, 496, and 8128.

In this article, we’ll delve into the concept of perfect numbers and explore various approaches to check if a given number falls into this intriguing category.

2. Understanding Perfect Numbers

Let’s examine the first few examples to grasp the concept of perfect numbers. The number 6, for instance, has proper divisors 1, 2, and 3. Summing these divisors yields 1 + 2 + 3 = 6, making 6 a perfect number. Similarly, the number 28 has proper divisors 1, 2, 4, 7, and 14, with their sum equating to 1 + 2 + 4 + 7 + 14 = 28. Hence, 28 is another perfect number.

We can employ different methodologies to determine whether a given number is perfect. Let’s explore three common approaches.

3. Brute Force Method

One way to check for perfection is by iterating through all possible divisors of the number and summing them. If the sum equals the number itself, we have a perfect number. This method can be implemented using a loop that traverses from 1 to n/2, where n is the given number. For each divisor found, we accumulate the sum. Finally, we compare the sum with the original number to determine perfection:

public static boolean isPerfectBruteForce(int number) {
    int sum = 0;
    for (int i = 1; i <= number / 2; i++) {
        if (number % i == 0) {
            sum += i;
        }
    }
    return sum == number;
}

The choice to iterate up to n/2 is based on the observation that the largest possible proper divisor of a number n, excluding n itself, is n/2. Divisors larger than n/2 would result in a quotient less than 2, which is not considered a proper divisor. This approach ensures that we cover all the necessary divisors efficiently.

The brute force method iterates through all possible divisors from 1 to n/2 and calculates the sum. The time complexity is linear concerning the input number.

4. Stream-based Method

We can also utilize Java Streams to check for perfect numbers. In this method, we generate a stream of divisors from 2 to the square root of the number being tested (rounded down), filter the divisors that evenly divide the number, and then calculate the sum by adding each divisor and its corresponding pair (number/test). Finally, we compare the sum with the original number to determine perfection:

public static boolean isPerfectStream(int number) {
    int sum = IntStream.rangeClosed(2, (int) Math.sqrt(number))
      .filter(test -> number % test == 0)
      .reduce(1, (s, test) -> s + test + (number / test));
    return sum == number;
}

When searching for divisors of a number, we can stop iterating once we reach the square root of the number. This is because factors always come in pairs. For example, if a is a divisor of a number, then b = number/a is also a divisor. If a is less than or equal to the square root of the number, then b will be greater than or equal to the square root of the number. Therefore, by finding divisors up to the square root, we have covered all possible factors.

The stream-based method uses Java Streams to filter and sum the divisors up to the square root of the number. By only looping up to the square root, we can reduce the amount of work needed to find the divisors and improve efficiency. This optimized approach significantly reduces the execution time compared to the previous attempts, making it a more efficient solution for checking perfect numbers.

5. Euclid-Euler Theorem

A more efficient method, based on the Euclid-Euler theorem, allows us to identify perfect numbers without iterating through all possible divisors. According to the theorem, if 2^(p-1) * (2^p – 1) is a prime number, then (2^p – 1) * 2^(p-1) is a perfect number. Here, p must be a prime number. By utilizing the theorem, we can focus on calculating perfect numbers based on the formula. This approach allows us to efficiently identify perfect numbers without the need to iterate through all possible divisors or explicitly find prime numbers:

public static boolean isPerfectEuclidEuler(int number) {
    int p = 2;
    int perfectNumber = (int) (Math.pow(2, p - 1) * (Math.pow(2, p) - 1));
    while (perfectNumber <= number) {
        if (perfectNumber == number) {
            return true;
        }
        p++;
        perfectNumber = (int) (Math.pow(2, p - 1) * (Math.pow(2, p) - 1));
    }
    return false;
}

The Euclid-Euler theorem method leverages prime numbers and calculates perfect numbers based on the theorem. The time complexity of the Euclid-Euler method is better than that of the brute force and stream-based methods because it only requires checking numbers up to log n.

Although the time complexity is better than the brute force and Stream-based methods, the execution time of the Euclid-Euler method we provided may not meet expectations. One reason for this suboptimal performance is the usage of Math.pow(), which is known for its slowness. Considering that we’re only calculating the power of base 2, we can improve the efficiency by utilizing binary shift operations instead of Math.pow():

public static boolean isPerfectEuclidEulerUsingShift(int number) {
    int p = 2;
    int perfectNumber = (2 << (p - 1)) * ((2 << p) - 1);
    while (perfectNumber <= number) {
        if (perfectNumber == number) {
            return true;
        }
        p++;
        perfectNumber = (2 << (p - 1)) * ((2 << p) - 1);
    }
    return false;
}

By replacing Math.pow() with binary shift operations (2 << p) for calculating powers of 2, we can achieve faster and more efficient calculations. This optimization significantly improves the performance of the Euclid-Euler method.

6. Analysis and Comparison

Let’s analyze and compare the three different methods we provided for checking perfect numbers.

The brute force method, although simple, iterates through all possible divisors and compares the sum with the original number. It is suitable for smaller numbers but becomes less efficient as the input size increases. This method has a time complexity linear to the input number, resulting in slower execution times for larger numbers.

The stream-based method offers a more concise and expressive implementation by utilizing Java Streams to filter and sum the divisors efficiently. By limiting the iteration to the square root of the number, it reduces unnecessary calculations and iterations, improving efficiency and reducing execution time. The stream-based method strikes a balance between simplicity and efficiency.

The Euclid-Euler theorem method provides the most efficient approach among the three. Leveraging the theorem’s formula allows us to calculate perfect numbers directly without checking all possible divisors. This method significantly reduces the computational effort and achieves remarkable efficiency. It is particularly effective for large numbers, as it avoids iterating through numerous divisors.

To compare the performance of these methods, we conducted benchmarking using JMH, a common tool for micro benchmarking Java programs. The benchmark was performed using a known perfect number, specifically 33550336. The results of the benchmark are:

Benchmark                                               Mode  Cnt         Score         Error  Units
PerfectNumberBenchmark.bruteForceBenchmark             thrpt    5        55.070 ±       2.674  ops/s
PerfectNumberBenchmark.streamBenchmark                 thrpt    5     96114.246 ±    3666.451  ops/s
PerfectNumberBenchmark.euclidEulerBenchmark            thrpt    5    144639.676 ±    3409.540  ops/s
PerfectNumberBenchmark.euclidEulerUsingShiftBenchmark  thrpt    5  99191865.954 ± 5924410.475  ops/s

The “Cnt” column represents the number of iterations performed for each benchmark mode. The “Score” column represents the throughput or the number of operations per second achieved by each benchmark. It indicates how often a particular operation or algorithm was executed within a second. The “Error” column represents the statistical error associated with the benchmark results. It provides an estimate of the variability or uncertainty in the measured values. A smaller error indicates more consistent and reliable results.

The Euclid-Euler method stands out as the most efficient approach, followed by the stream-based method. The brute force method, while straightforward, is less efficient and more suitable for smaller numbers. When dealing with larger numbers, the Euclid-Euler or stream-based methods are recommended for optimal performance.

7. Conclusion

In this article, we explored the fascinating concept of perfect numbers and examined various approaches to determine if a given number falls into this category.

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

       

1. Overview

When working with Java in the Eclipse IDE, ensuring the correct Java version is essential for compiling and executing code accurately. Eclipse simplifies this process by providing straightforward methods to check and configure the Java version it uses. In this tutorial, we’ll walk through the steps to determine the Java version running in Eclipse.

2. Java in Eclipse: Environment vs. Project Configuration

It’s important to differentiate between the Java version used within Eclipse itself, which may differ from the Java version configured for specific projects within Eclipse.

While Eclipse’s own Java version impacts its operations and functionalities, individual projects within Eclipse can be configured to use different JDKs or JREs based on project requirements. This allows us to tailor the Java environment for each project, ensuring compatibility and optimal performance. Therefore, while it’s crucial to determine the Java version running in Eclipse, we should also be mindful of project-specific Java configurations to avoid compatibility issues and ensure smooth development workflows.

3. Checking Which Java Version Is Running in Eclipse

In this section, we’ll explore how to determine the Java version currently running in the Eclipse IDE.

3.1. Using the Eclipse IDE Installation Details

To start, let’s open the Eclipse IDE and then navigate to “Help” in the menu bar. Then, we can select “About Eclipse IDE“:

Within the “About Eclipse IDE” dialog box, let’s click on the “Installation Details” button:

In the ensuing popup, we switch to the “Configuration” tab:

Under the Configuration tab, we can locate essential Java properties that provide valuable information about the Eclipse IDE Java configuration. These properties include:

• java.version: specifies the Java Development Kit (JDK) version being utilized
• java.runtime.version: indicates the version of the Java Runtime Environment (JRE) currently in use
• java.vm.version: specifies the version of the Java Virtual Machine (JVM)

In the above example, the Eclipse IDE is running under Java version 17.0.10.

3.2. Checking the eclipse.ini File

Another way to determine the Java version used in Eclipse is to inspect the eclipse.ini file. Typically located within the Eclipse installation directory, this file contains configuration settings for Eclipse IDE, including the Java configuration.

Let’s open this file in a text editor and locate the line that starts with -vm, which specifies the location of the Java executable that Eclipse should use:

While the -vm option in the eclipse.ini file specifies the path to the Java executable, it doesn’t directly reveal the exact Java version used in Eclipse IDE. For instance, the path specified in our eclipse.ini file provides insights suggesting Eclipse’s usage of Java 17. However, a path like C:\Program\Java\jdk\bin offers no indication regarding the Java version in use.

To determine the exact Java version, we need to navigate to the path defined in the -vm option of the eclipse.ini file and execute java –version in a command prompt.

The -vm option provides flexibility as we can modify the associated path to point to a different JDK installation directory. Also, removing these lines allows Eclipse to use the Java version specified in the PATH system environment variable.

3. Conclusion

Identifying the Java version running in Eclipse is essential for us to ensure compatibility and leverage the latest language features.

By following the methods in this article, we can easily determine the Java version configured within Eclipse. This understanding empowers us to make informed decisions while developing Java applications within the Eclipse IDE.

       

1. Overview

The transaction mechanism in JPA is a powerful tool that ensures atomicity and data integrity by either committing all changes or rolling them back in case of an exception. However, there are scenarios where continuing with the transaction after encountering an exception, without rolling back the data changes, becomes necessary.

In this article, we’ll delve into various use cases where this situation arises. Additionally, we’ll explore potential solutions for such cases.

2. Determining the Issue

We have two main cases where exceptions may occur within the transaction. Let’s start by understanding them.

2.1. Rollback the Transaction After Exception in the Service Layer

The first place where we may encounter the rollback is in the service layer, where an external exception could affect the database changes.

Let’s examine this scenario more closely using the following example. First things first, let’s add the InvoiceEntity, which serves as our data model:

@Entity
@Table(uniqueConstraints = {@UniqueConstraint(columnNames = "serialNumber")})
public class InvoiceEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Integer id;
    private String serialNumber;
    private String description;
    //Getters and Setters
}

Here, we have an internal ID that will be generated automatically, a serial number that needs to be unique across the system, and a description.

Now, let’s create the InvoiceService responsible for transactional operations on our invoices:

@Service
public class InvoiceService {
    @Autowired
    private InvoiceRepository repository;
    
    @Transactional
    public void saveInvoice(InvoiceEntity invoice) {
        repository.save(invoice);
        sendNotification();
    }
    
    private void sendNotification() {
        throw new NotificationSendingException("Notification sending is failed");
    }
}

Inside the saveInvoice() method, we added the logic that should transactionally save the invoice and send the notification about it. Unfortunately, during the notification-sending process, we’ll face the exception:

public class NotificationSendingException extends RuntimeException {
    public NotificationSendingException(String text) {
        super(text);
    }
}

We don’t have anything specifically implemented, just a RuntimeException exception. Let’s observe the behavior in this scenario:

@Autowired
private InvoiceService service;
@Test
void givenInvoiceService_whenExceptionOccursDuringNotificationSending_thenNoDataShouldBeSaved() {
    InvoiceEntity invoiceEntity = new InvoiceEntity();
    invoiceEntity.setSerialNumber("#1");
    invoiceEntity.setDescription("First invoice");
    assertThrows(
        NotificationSendingException.class,
        () -> service.saveInvoice(invoiceEntity)
    );
    List<InvoiceEntity> entityList = repository.findAll();
    Assertions.assertTrue(entityList.isEmpty());
}

We invoked the saveInvoice() method from the service, encountered the NotificationSendingException, and, as expected, all the database changes were rolled back.

2.2. Rollback the Transaction After Exception in the Persistence Layer

Another case where we can face the implicit rollback is in the persistence layer.

We may assume that if we caught the exception from databases we’re able to continue our logic of data manipulation within the same transaction. But that’s not the case. Let’s create a saveBatch() method in our InvoiceRepository and try to reproduce the issue:

@Repository
public class InvoiceRepository {
    private final Logger logger = LoggerFactory.getLogger(
      com.baeldung.continuetransactionafterexception.InvoiceRepository.class);
    @PersistenceContext
    private EntityManager entityManager;
    @Transactional
    public void saveBatch(List<InvoiceEntity> invoiceEntities) {
        invoiceEntities.forEach(i -> entityManager.persist(i));
        try {
            entityManager.flush();
        } catch (Exception e) {
            logger.error("Exception occured during batch saving, save individually", e);
            invoiceEntities.forEach(i -> {
                try {
                    save(i);
                } catch (Exception ex) {
                    logger.error("Problem saving individual entity {}", i.getSerialNumber(), ex);
                }
            });
        }
    }
}

In the saveBatch() method, we attempt to save the list of objects using a single flush operation. If any exception occurs during this operation, we catch it and proceed to save each object individually. Let’s implement the save() method in the following way:

@Transactional
public void save(InvoiceEntity invoiceEntity) {
    if (invoiceEntity.getId() == null) {
        entityManager.persist(invoiceEntity);
    } else {
        entityManager.merge(invoiceEntity);
    }
    entityManager.flush();
    logger.info("Entity is saved: {}", invoiceEntity.getSerialNumber());
}

We handle each exception by catching and logging it to avoid triggering a transaction rollback. Let’s call it and see how it works:

@Test
void givenInvoiceRepository_whenExceptionOccursDuringBatchSavingInternally_thenNoDataShouldBeSaved() {
    List<InvoiceEntity> testEntities = new ArrayList<>();
    InvoiceEntity invoiceEntity = new InvoiceEntity();
    invoiceEntity.setSerialNumber("#1");
    invoiceEntity.setDescription("First invoice");
    testEntities.add(invoiceEntity);
    InvoiceEntity invoiceEntity2 = new InvoiceEntity();
    invoiceEntity2.setSerialNumber("#1");
    invoiceEntity.setDescription("First invoice (duplicated)");
    testEntities.add(invoiceEntity2);
    InvoiceEntity invoiceEntity3 = new InvoiceEntity();
    invoiceEntity3.setSerialNumber("#2");
    invoiceEntity.setDescription("Second invoice");
    testEntities.add(invoiceEntity3);
    UnexpectedRollbackException exception = assertThrows(UnexpectedRollbackException.class,
      () -> repository.saveBatch(testEntities));
    assertEquals("Transaction silently rolled back because it has been marked as rollback-only",
      exception.getMessage());
    List<InvoiceEntity> entityList = repository.findAll();
    Assertions.assertTrue(entityList.isEmpty());
}

We’ve prepared a list of invoices, two of which violate the unique constraint on the serial number field. When attempting to save this list of invoices, we encounter the UnexpectedRollbackException, and no items are saved in the database. This occurs because, after the first exception, our transaction was marked as rollback only, preventing any further commits from taking place within it.

3. Use noRollbackFor Property of the @Transactional Annotation

For the cases where the exception happens outside the JPA calls, we can use the noRollbackFor property of the @Transactional annotation to retain the database changes if some expected exception occurred in the same transaction.

Let’s modify our saveInvoiceWithoutRollback() method in the InvoiceService class:

@Transactional(noRollbackFor = NotificationSendingException.class)
public void saveInvoiceWithoutRollback(InvoiceEntity entity) {
    repository.save(entity);
    sendNotification();
}

Now, let’s call this method and see how the behavior is changed:

@Test
void givenInvoiceService_whenNotificationSendingExceptionOccurs_thenTheInvoiceBeSaved() {
    InvoiceEntity invoiceEntity = new InvoiceEntity();
    invoiceEntity.setSerialNumber("#1");
    invoiceEntity.setDescription("We want to save this invoice anyway");
    assertThrows(
      NotificationSendingException.class,
      () -> service.saveInvoiceWithoutRollback(invoiceEntity)
    );
    List<InvoiceEntity> entityList = repository.findAll();
    Assertions.assertTrue(entityList.contains(invoiceEntity));
}

As expected, we got NotificationSendingException. However, the invoice was saved successfully in the database.

4. Use Transactions Manually

In cases where we encounter rollback in the persistence layer, we can manually control transactions to ensure that data is saved even if an exception occurs.

Let’s inject the EntityManagerFactory into our InvoiceRepository and create a method to create the EntityManager:

@Autowired
private EntityManagerFactory entityManagerFactory;
private EntityManager em() {
    return entityManagerFactory.createEntityManager();
}

We’ll not use shared EntityManager in this example since it doesn’t allow us to manipulate transactions manually. Now, let’s implement the saveBatchUsingManualTransaction() method:

public void saveBatchUsingManualTransaction(List<InvoiceEntity> testEntities) {
    EntityTransaction transaction = null;
    try (EntityManager em = em()) {
        transaction = em.getTransaction();
        transaction.begin();
        testEntities.forEach(em::persist);
        try {
            em.flush();
        } catch (Exception e) {
            logger.error("Duplicates detected, save individually", e);
            transaction.rollback();
            testEntities.forEach(t -> {
                EntityTransaction newTransaction = em.getTransaction();
                try {
                    newTransaction.begin();
                    saveUsingManualTransaction(t, em);
                } catch (Exception ex) {
                    logger.error("Problem saving individual entity <{}>", t.getSerialNumber(), ex);
                    newTransaction.rollback();
                } finally {
                    commitTransactionIfNeeded(newTransaction);
                }
            });
        }
    } finally {
        commitTransactionIfNeeded(transaction);
    }
}

Here, we begin the transaction,  persist all the items, flush the changes, and commit the transaction. If any exception occurs, we roll back the current transaction and save each item individually using separate transactions. In saveUsingManualTransaction(), we’ve implemented the next code:

private void saveUsingManualTransaction(InvoiceEntity invoiceEntity, EntityManager em) {
    if (invoiceEntity.getId() == null) {
        em.persist(invoiceEntity);
    } else {
        em.merge(invoiceEntity);
    }
    em.flush();
    logger.info("Entity is saved: {}", invoiceEntity.getSerialNumber());
}

We added the same logic as in the save() method, but we used entity manager from the method parameters. In the commitTransactionIfNeeded(), we’ve implemented the commit logic:

private void commitTransactionIfNeeded(EntityTransaction newTransaction) {
    if (newTransaction != null && newTransaction.isActive()) {
        if (!newTransaction.getRollbackOnly()) {
            newTransaction.commit();
        }
    }
}

Finally, let’s use the new repository method and see how it handles exceptions:

@Test
void givenInvoiceRepository_whenExceptionOccursDuringBatchSavingInternally_thenDataShouldBeSavedInSeparateTransaction() {
    List<InvoiceEntity> testEntities = new ArrayList<>();
    InvoiceEntity invoiceEntity1 = new InvoiceEntity();
    invoiceEntity1.setSerialNumber("#1");
    invoiceEntity1.setDescription("First invoice");
    testEntities.add(invoiceEntity1);
    InvoiceEntity invoiceEntity2 = new InvoiceEntity();
    invoiceEntity2.setSerialNumber("#1");
    invoiceEntity1.setDescription("First invoice (duplicated)");
    testEntities.add(invoiceEntity2);
    InvoiceEntity invoiceEntity3 = new InvoiceEntity();
    invoiceEntity3.setSerialNumber("#2");
    invoiceEntity1.setDescription("Second invoice");
    testEntities.add(invoiceEntity3);
    repository.saveBatchUsingManualTransaction(testEntities);
    List<InvoiceEntity> entityList = repository.findAll();
    Assertions.assertTrue(entityList.contains(invoiceEntity1));
    Assertions.assertTrue(entityList.contains(invoiceEntity3));
}

We called the batch method with the invoices list that contains duplicates. But now, we can see that two of three invoices were successfully saved.

5. Split the Transaction

We can get the same behavior as in the previous section using @Transactional annotated methods. The only issue is we can not call all these methods inside the one bean, as we did when using transactions manually. But, we can create two @Transactional annotated methods in our InvoiceRepository and call them from our client code. Let’s implement the saveBatchOnly() method:

@Transactional
public void saveBatchOnly(List<InvoiceEntity> testEntities) {
    testEntities.forEach(entityManager::persist);
    entityManager.flush();
}

Here, we’ve added only the batch-saving implementation. The save() method is reused from the examples in previous sections. Now, let’s see how we can use these two methods:

@Test
void givenInvoiceRepository_whenExceptionOccursDuringBatchSaving_thenDataShouldBeSavedUsingSaveMethod() {
    List<InvoiceEntity> testEntities = new ArrayList<>();
    InvoiceEntity invoiceEntity1 = new InvoiceEntity();
    invoiceEntity1.setSerialNumber("#1");
    invoiceEntity1.setDescription("First invoice");
    testEntities.add(invoiceEntity1);
    InvoiceEntity invoiceEntity2 = new InvoiceEntity();
    invoiceEntity2.setSerialNumber("#1");
    invoiceEntity1.setDescription("First invoice (duplicated)");
    testEntities.add(invoiceEntity2);
    InvoiceEntity invoiceEntity3 = new InvoiceEntity();
    invoiceEntity3.setSerialNumber("#2");
    invoiceEntity1.setDescription("Second invoice");
    testEntities.add(invoiceEntity3);
    try {
        repository.saveBatchOnly(testEntities);
    } catch (Exception e) {
        testEntities.forEach(t -> {
            try {
                repository.save(t);
            } catch (Exception e2) {
                System.err.println(e2.getMessage());
            }
        });
    }
    List<InvoiceEntity> entityList = repository.findAll();
    Assertions.assertTrue(entityList.contains(invoiceEntity1));
    Assertions.assertTrue(entityList.contains(invoiceEntity3));
}

We save the entity list that contains duplicates using the saveBatchOnly() method. If any exception occurs, we use the save() method in the loop to save all the items individually if it’s possible. Finally, we can see that all expected items were saved.

6. Conclusion

Transactions are a powerful mechanism that enables us to perform atomic operations. Rollback is the expected behavior for failed transactions. However, in certain scenarios, we may need to proceed with our work despite the failure and ensure that our data is saved. We’ve reviewed various approaches to achieve this. We can choose the one that best suits our specific situation.

As usual, the full source code can be found over on GitHub.

       

1. Overview

In this tutorial, we’ll discuss testing code that uses Spring application events. We’ll start by manually creating test utilities that help us publish and collect application events for testing purposes.

After that, we’ll discover Spring Modulith‘s testing library and use its fluent Scenario API to discuss the common test cases. Using this declarative DSL, we’ll write expressive tests that can easily produce and consume application events.

2. Application Events

Spring Framework offers application events to allow components to communicate with each other while maintaining a loose coupling. We can use the ApplicationEventPublisher bean to publish internal events, which are plain Java objects. Consequently, all the registered listeners are notified.

For example, the OrderService component can publish an OrderCompletedEvent when an Order is placed successfully:

@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;
    
    // constructor
    public void placeOrder(String customerId, String... productIds) {
        Order order = new Order(customerId, Arrays.asList(productIds));
	// business logic to validate and place the order
	OrderCompletedEvent event = new OrderCompletedEvent(savedOrder.id(), savedOrder.customerId(), savedOrder.timestamp());
	eventPublisher.publishEvent(event);
    }
}

As we can see, the completed orders are now published as application events. Therefore, components from different modules can now listen to these events and react accordingly.

Let’s assume that LoyaltyPointsService reacts to these events to reward customers with loyalty points. To implement this, we can leverage Spring’s @EventListener annotation:

@Service
public class LoyaltyPointsService {
    private static final int ORDER_COMPLETED_POINTS = 60;
    private final LoyalCustomersRepository loyalCustomers;
    // constructor
    @EventListener
    public void onOrderCompleted(OrderCompletedEvent event) {
        // business logic to reward customers
        loyalCustomers.awardPoints(event.customerId(), ORDER_COMPLETED_POINTS);
    }
}

Using application events instead of a direct method invocation allowed us to keep a looser coupling and invert the dependency between the two modules. In other words, the “orders” module doesn’t have source code dependencies on the classes from the “rewards” module.

3. Testing Event Listeners

We can test a component that uses @EventListener by publishing an application event from within the test itself.

To test LoyaltyPointsService, we’ll need to create a @SpringBootTest, inject the ApplicationEventPublisher bean, and use it to publish an OrderCompletedEvent:

@SpringBootTest
class EventListenerUnitTest {
    @Autowired
    private LoyalCustomersRepository customers;
    @Autowired
    private ApplicationEventPublisher testEventPublisher;
    @Test
    void whenPublishingOrderCompletedEvent_thenRewardCustomerWithLoyaltyPoints() {
        OrderCompletedEvent event = new OrderCompletedEvent("order-1", "customer-1", Instant.now());
        testEventPublisher.publishEvent(event);
	// assertions
    }
}

Finally, we need to assert that LoyaltyPointsService consumed the event and rewarded the customer with the correct number of points. Let’s use LoyalCustomersRepository to see how many loyalty points were awarded to this customer:

@Test
void whenPublishingOrderCompletedEvent_thenRewardCustomerWithLoyaltyPoints() {
    OrderCompletedEvent event = new OrderCompletedEvent("order-1", "customer-1", Instant.now());
    testEventPublisher.publishEvent(event);
    assertThat(customers.find("customer-1"))
      .isPresent().get()
      .hasFieldOrPropertyWithValue("customerId", "customer-1")
      .hasFieldOrPropertyWithValue("points", 60);
}

As expected, the test passes: the event is received and processed by the “rewards” module, and the bonus is applied.

4. Testing Event Publishers

We can test a component that publishes application events by creating a custom event listener in the test package.  This listener will also use the @EventHandler annotation, similar to the production implementation. However, this time we’ll collect all the incoming events into a list that will be exposed via a getter:

@Component
class TestEventListener {
    final List<OrderCompletedEvent> events = new ArrayList<>();
    // getter
    @EventListener
    void onEvent(OrderCompletedEvent event) {
        events.add(event);
    }
    void reset() {
        events.clear();
    }
}

As we can observe, we can also add the utility reset(). We can call it before each test, to clear the events produced by the previous one. Let’s create the Spring Boot test and @Autowire our TestEventListener component:

@SpringBootTest
class EventPublisherUnitTest {
    @Autowired
    OrderService orderService;
    @Autowired
    TestEventListener testEventListener;
    @BeforeEach
    void beforeEach() {
        testEventListener.reset();
    }
    @Test
    void whenPlacingOrder_thenPublishApplicationEvent() {
        // place an order
        assertThat(testEventListener.getEvents())
          // verify the published events
    }
}

To finish the test, we’ll need to place an order using the OrderService component. After that, we’ll assert that testEventListener received exactly one application event, having adequate properties:

@Test
void whenPlacingOrder_thenPublishApplicationEvent() {
    orderService.placeOrder("customer1", "product1", "product2");
    assertThat(testEventListener.getEvents())
      .hasSize(1).first()
      .hasFieldOrPropertyWithValue("customerId", "customer1")
      .hasFieldOrProperty("orderId")
      .hasFieldOrProperty("timestamp");
}

If we look closely, we’ll notice that the setup and verification of these two tests complement each other. This test simulates a method call and listens for the published event, whereas, the previous one publishes an event and verifies a state change. In other words, we’ve tested the entire process by using just two tests: each one covering a distinct segment, split at the logical module boundary.

5. Spring Modulith’s Test Support

Spring Modulith offers a collection of artifacts that can be used independently. These libraries provide a range of functionalities primarily aimed at establishing clear boundaries between logical modules within an application.

5.1. The Scenario API

This architectural style promotes a flexible interaction between modules by utilizing application events. Therefore, one of the artifacts within the Spring Modulith offers support for testing flows that involve application events.

Let’s add spring-modulith-starter-test maven dependency to our pom.xml:

<dependency>
    <groupId>org.springframework.modulith</groupId>
    <artifactId>spring-modulith-starter-test</artifactId>
    <version>1.1.3</version>
</dependency>

This allows us to write tests in a declarative way, using the Scenario API. First, we’ll create a test class and annotate it with @ApplcationModuleTest. As a result, we’ll be able to inject the Scenario object in any of the test methods:

@ApplicationModuleTest
class SpringModulithScenarioApiUnitTest {
 
    @Test
    void test(Scenario scenario) {
        // ...
    }
}

Simply put, this feature offers a convenient DSL that allows us to test the most common use cases. For example, it makes it easy to initiate the test and evaluate its outcome by:

• performing method calls
• publishing application events
• verifying state changes
• capturing and verifying outgoing events

Additionally, the API offers a few other utilities, such as:

• polling and waiting for asynchronous application events
• defining timeouts
• perform filtering and mapping on the captured events
• creating custom assertions

5.2. Testing Event Listeners Using Scenario API

To test components using @EventListener methods, we had to inject the ApplicationEventPublisher bean and publish an OrderCompletedEvent. However, Spring Modulith’s test DSL provides a more straightforward solution via scenario.publish():

@Test
void whenReceivingPublishOrderCompletedEvent_thenRewardCustomerWithLoyaltyPoints(Scenario scenario) {
    scenario.publish(new OrderCompletedEvent("order-1", "customer-1", Instant.now()))
      .andWaitForStateChange(() -> loyalCustomers.find("customer-1"))
      .andVerify(it -> assertThat(it)
        .isPresent().get()
        .hasFieldOrPropertyWithValue("customerId", "customer-1")
        .hasFieldOrPropertyWithValue("points", 60));
}

The method andWaitforStateChange() accepts a lambda expression and it retries executing it until it returns a non-null object or a non-empty Optional. This mechanism can be particularly useful for asynchronous method calls.

To conclude, we defined a scenario where we publish an event, wait for a state change, and then, verify the final state of the system. 

5.3. Testing Event Publishers Using Scenario API

We can also use the Scenario API to simulate a method call, and intercept, and verify outgoing application events. Let’s use the DSL to write a test that validates the behavior of the “order” module: 

@Test
void whenPlacingOrder_thenPublishOrderCompletedEvent(Scenario scenario) {
    scenario.stimulate(() -> orderService.placeOrder("customer-1", "product-1", "product-2"))
      .andWaitForEventOfType(OrderCompletedEvent.class)
      .toArriveAndVerify(evt -> assertThat(evt)
        .hasFieldOrPropertyWithValue("customerId", "customer-1")
        .hasFieldOrProperty("orderId")
        .hasFieldOrProperty("timestamp"));
}

As we can see, the method andWaitforEventOfType() allows us to declare the type of event we want to capture. Following that, toArriveAndVerify() is used to wait for the event and perform the relevant assertions.

6. Conclusion

In this article, we saw various ways of testing code using Spring application events. In our first test, we used an ApplicationEventPublisher to manually publish the application events.

Similarly, we created a custom TestEventListener that uses the @EventHandler annotation to capture all the outgoing events. We used this helper component to capture and verify the events produced by our application during the test.

After that, we learned about Spring Modulith’s testing support and we used the Scenario API to write the same tests in a declarative fashion. The fluent DSL allowed us to publish and capture application events, simulate method calls, and await state changes.

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

       

1. Overview

In this tutorial, let’s discuss the PostgreSQL exception, FATAL: sorry, too many clients already. Generally, the PostgreSQL server throws this error when it cannot accept a connection request from a client application.

We’ll explore its causes, troubleshoot the issue, and understand some guidelines to prevent it.

2. How, When and Why

The DB server starts with a limited number of connections. Sometimes the connections are exhausted. Consequently, the DB server cannot serve new connections. That’s when it throws the exception, FATAL: sorry, too many clients already.

First, let’s understand how, when, and why this issue occurs. Let’s assume four client applications connect to a PostgreSQL database:

Mostly, applications implement connection pooling during the boot-up time. Suppose, the database administrator configured the PostgreSQL database server for a maximum of 90 connections. We must remember, that the database reserves some connections for its internal use. The actual connections available for clients are even fewer. The application deployment team configures each client application with a connection pool size of 30.

Now let’s say the deployment team brings up the client applications sequentially, starting with Client-1. When Client-4 tries to start, the client applications Client-1, Client-2, and Client-3 have already acquired and blocked 90 connections. Hence, when Client-4 requests 30 more connections from the database server, the server rejects the request with the error FATAL: sorry, too many clients already.

The error can also occur when developers try to connect to the PostgreSQL server using database management tools such psql, pgAdmin, DBeaver, etc. After all, these tools also try to acquire connections to the database and in the event of inadequate connections, they might also face the same error.

3. How to Troubleshoot

First, let’s start with determining the maximum number of connections by running a query in the PostgreSQL database:

show max_connections

By default, it’s set to 100, however it can have higher values. We can set it by modifying the PostgreSQL runtime connection setting max_connections in postgresql.conf file present in the database server:

/var/lib/postgresql/data # cat postgresql.conf | grep max_connections
max_connections = 100                   # (change requires restart)

However, we should first investigate the high usage of database connections instead of setting it to a higher value, for a permanent solution.

When the client applications report such errors, we must ascertain the number of active connections to the database server. For each active connection, a backend process runs in the database server. The PostgreSQL database tracks these backend processes in the pg_stat_activity view. We can run an SQL query on it to fetch the active and idle connections:

select pid, datname, application_name, client_addr, state 
from pg_stat_activity 
where state in ('idle', 'active')

Let’s take a look at a sample output showing the connection details:

Let’s understand the meaning of the columns in the output:

After discovering the active and idle connections, we can identify the inconsequential ones and stop or kill the backend processes holding them up. Moreover, we can also forcibly terminate the sessions from the database using the pg_terminate_backend system administration function:

select pg_terminate_backend(147)

The database function pg_terminate_backend() takes the backend process ID 147 and terminates it.

4. How to Prevent

The primary step to prevent the error is to accurately benchmark the application to assess its database server connection requirement. After benchmarking, we can size and configure the database server for the maximum connection requirement. Then, the deployment team can set the optimum connection pool size in the application.

Additionally, we should be cautious in setting the connection pool size of the application processes in environments where auto-scaling is enabled. When new processes are spawned automatically in environments such as in a Kubernetes cluster, the connection size in the database might be inadequate for serving more connection requests.

Developers should set proper connection timeouts in the applications and close connections appropriately. Consequently, connections aren’t held up for longer durations and are returned to the pool or the database server.

Developers should diligently exit database management tools such as pgAdmin, DBeaver, etc. once they finish their work. Configuring these tools to close connections and sessions after a certain period of inactivity is a good practice.

Infrastructure and network engineers should restrict the connectivity to the database server. Additionally, database administrators can configure the database to manage the source IPs allowed to connect.

5. Conclusion

In this article, we discussed the PostgreSQL error FATAL: sorry, too many clients already.

Prevention is always better than cure, hence we must benchmark applications to ascertain their database connection requirements. Furthermore, we must configure the operating environment to allow only the necessary connections to the database and nothing more than that.

       

1. Overview

We may wish to process a telephone number expressed as text. Perhaps we have received a telephone number via a speech-to-text interface.

In this tutorial, we’ll look at an algorithm for processing a sequence of words expressing a numeric sequence and converting it to a string of digits.

2. Introduction to Problem Statement

Let’s look a little deeper at the format of the input. We’ll be given a phone number in words, such as “five six eight”. However, it’s common for spoken numbers to include multipliers, such as “double two”.

So, we expect our algorithm to convert:

Input: "triple five two three six eight"
Expected Output: "5552368"

3. Implementing the Algorithm with switch Statements

The algorithm splits the input into words and processes each to build the output. We can classify the words using switch statements.

3.1. Split String into Words Array

First, we need to use the String.split() method to split the phoneNumberInWords string into an array of words using a space as the delimiter:

String[] words = phoneNumberInWords.split(" ");

We can then use a for-each loop to iterate over the words array:

for (String word : words) {
    // statements
}

3.2. Handle Multipliers

In each iteration of the for-each loop, we will check if the current word represents a multiplier:

Integer multiplier = getWordAsMultiplier(word);
if (multiplier != null) {
    if (currentMultiplier != null) {
        throw new IllegalArgumentException("Cannot have consecutive multipliers, at: " + word);
    }
    currentMultiplier = multiplier;
}

We invoke the getWordAsMultiplier() method by passing the current word as an argument. This method maps the current word to its corresponding numerical representation and returns it.

If the returned value is not null, indicating the current word is indeed a multiplier, we check if there is already a multiplier set. If there is, we throw an IllegalArgumentException because consecutive multipliers are not allowed. Otherwise, we set the current multiplier.

To identify whether a word is a multiplier, we use a switch statement inside getWordAsMultiplier():

public static Integer getWordAsMultiplier(String word) {
    switch (word) {
        case "double":
            return 2;
        case "triple":
            return 3;
         case "quadruple":
            return 4;
         default:
            return null;
    }
}

It’s not an error if the current word isn’t a multiplier, so this method returns null in that instance.

3.3. Handle Non-multiplier Word

If the current word isn’t a multiplier word, we call the getWordAsDigit() method:

public static String getWordAsDigit(String word) {
    switch (word) {
        case "zero":
            return "0";
        case "one":
            return "1";
        ...
        ...
        ...
        case "nine":
            return "9";
        default:
            throw new IllegalArgumentException("Invalid word: " + word);
    }
}

This will be called in the else statement of the if where we check for a multiplier word. As a word must be either a multiplier or a digit, this function should throw an exception if we call it with a non-digit number. Here, we’ve used IllegalArgumentException.

3.4. Assembling Digits

Let’s use the getWordAsDigit() method. In the multiplier processing code, we’ve captured any duplication of digits, so now we’re going to find the current digit and add it to the output as many times as necessary.

We’ll use a StringBuilder object called output to store our results.

We use the append() method to assemble the output. However, the String.repeat() method tracks the multiplier. We repeat the obtained digit representation of the current word based on the current multiplier:

if (multiplier != null) {
    // multiplier processing
} else {
   output.append(getWordAsDigit(word)
     .repeat(currentMultiplier != null ? currentMultiplier : 1));
   currentMultiplier = null;
}

We use StringBuilder.append() to add the next set of digits to the output.

If the current multiplier is not null, we use it to provide copies of the next digit, using String.repeat(), defaulting to a repeat of 1 when there is no multiplier.

At the end of the loop, the output object contains our phone number:

return output.toString();

3.5. Test Solution

Let’s see what happens when a correct phone number, invalid word, or consecutive multipliers are given:

assertEquals("5248888", 
  UseSwitchToConvertPhoneNumberInWordToNumber 
    .convertPhoneNumberInWordToNumber("five two four quadruple eight"));
assertThrows(IllegalArgumentException.class, () -> {
    UseSwitchToConvertPhoneNumberInWordToNumber
      .convertPhoneNumberInWordToNumber("five eight invalid two four null eight");
});
assertThrows(IllegalArgumentException.class, () -> {
    UseSwitchToConvertPhoneNumberInWordToNumber
      .convertPhoneNumberInWordToNumber("five eight three double triple");
});

4. Using Map Instead of switch

Our algorithm works well, but switch statements can be a little long-winded. We can replace them with Map objects.

The Map.of() method creates an immutable Map with the provided key-value pairs. In this section, we’ll use the Map.of() method to map multipliers (“double” to 2) and digits (“two” to “2”).

4.1. Map Digits and Multipliers

Let’s initialize the Map to create mappings for individual digits:

private static Map<String, Integer> multipliers 
  = Map.of("double", 2, "triple", 3, "quadruple", 4);

Next, we initialize another Map to map multipliers:

private static Map<String, String> digits 
  = Map.of("zero", "1", "one", "1", "two", "2", "three", "3",
    "four", "4", "five", "5", "six", "6", "seven", "7", "eight", "8", "nine", "9");

We initialize them as immutable because the algorithm would stop working if the Map could change at runtime.

4.2. Check Multiplier

As before, inside the loop, we want to find a multiplier or null. We can use the get() method on multipliers:

Integer multiplier = multipliers.get(word);

4.3. Check Digits

To replicate the exception, when a word is not a digit, we need an additional if statement after the get() on digits:

String digit = digits.get(word);
if (digit == null) {
    throw new IllegalArgumentException("Invalid word: " + word);
}

4.4. Test Solution

We can run the same tests on this solution, such as:

assertEquals("5248888",
  UseHashMapToConvertPhoneNumberInWordsToNumber
    .convertPhoneNumberInWordToNumber("five two four quadruple eight"));

5. Conclusion

In this article, we looked at an algorithm for processing telephone numbers.

We implemented the basic algorithm using switch statements. Then, we optimized the implementation using Java Map.

As always, the example code is over on GitHub.

       

1. Overview

Error handling is a critical aspect of reactive programming with Spring WebFlux. Developers usually rely on two primary methods for error handling: throwing exceptions or using the Mono.error() method provided by Project Reactor. Both approaches are used to signal errors, but they have distinct characteristics and use cases.

In this tutorial, we will explain the differences between throwing an exception and Mono.error() in Spring WebFlux. We’ll provide illustrative Java code examples to make it more understandable.

2. Traditional Approach: Throwing Exceptions

For many years, throwing exceptions has been a reliable way of managing errors in Java applications. It is a simple way to interrupt the regular flow of the program and convey errors to the application’s higher layers. Spring WebFlux integrates smoothly with this conventional error-handling method, enabling developers to throw exceptions in their reactive endpoints. The code below represents an example of the conventional approach:

public Mono<User> getUserByIdThrowingException(String id) {
    User user = userRepository.findById(id);
    if (user == null) {
       throw new NotFoundException("User Not Found");
    }
    return Mono.justOrEmpty(user);
}

In this particular scenario, the getUserByIdThrowingException() method attempts to retrieve user data based on the ID provided by the UserRepository. If the user cannot be found, the method throws a NotFoundException, which signals the error within the reactive pipeline.

To perform unit testing, we import the assertThrows method from org.junit.jupiter.api.Assertions. This tests if getUserByIdThrowingException() throws a NotFoundException for users that are not found in the database. We use assertThrows with a lambda to execute the method call that should throw an exception.

If an exception is thrown, the code verifies that the thrown exception is of the expected type. However, if the method does not throw an exception, the test fails:

@Test
public void givenNonExistUser_whenFailureCall_then_Throws_exception() {
    assertThrows(
        NotFoundException.class,
        () -> userService.getUserByIdThrowingException("3")
    );
}

3. Embracing Reactivity: Mono.error()

In contrast to the traditional approach of throwing exceptions, Project Reactor introduces a reactive alternative through the Mono.error() method. This method generates a Mono that immediately terminates with an error signal, aligning seamlessly with the reactive programming paradigm.

Let’s examine the modified example utilizing Mono.error():

public Mono<User> getUserByIdUsingMonoError(String id) {
    User user = userRepository.findById(id);
    return (user != null)
      ? Mono.justOrEmpty(user)
      : Mono.error(new NotFoundException("User Not Found"));
}

To maintain a smooth user experience and consistent reactive flow, we use Mono.error() instead of throwing exceptions directly for unfound users in the database.

Here is the unit test for this method:

@Test
 public void givenNonExistUser_whenFailureCall_then_returnMonoError() {
    Mono result = userService.getUserByIdUsingMonoError("3");
    StepVerifier.create(result)
      .expectError(NotFoundException.class)
      .verify();
}

4. Understanding Key Differences and Use Cases

4.1. Control Flow Disruption

We use exceptions with try-catch or reactive operators like onErrorResume, onErrorReturn, or onErrorMap when signaled by Mono.error().

4.2. Laziness

Mono.error() now supports lazy instantiation of exceptions, which is beneficial in scenarios where constructing the exception involves resource-intensive operations.

4.3. Reactive Error Handling

Mono.error() aligns well with reactive programming paradigms, facilitating reactive error handling within the reactive stream.

5. Conclusion

In this article, we have discussed the fundamental differences between throwing exceptions and utilizing Mono.error() in Spring WebFlux for error handling in reactive applications; although both approaches serve the same purpose of signaling errors, they differ significantly in their control flow and integration with reactive pipelines.

Throwing exceptions interrupts the execution flow and transfers control to the nearest exception handler, making it suitable for imperative code paths. Conversely, Mono.error() seamlessly integrates with reactive streams, enabling asynchronous error signaling without halting the execution flow.

When developing reactive applications using Spring WebFlux, choosing the right error-handling mechanism is crucial based on the context and requirements. We use Mono.error() in reactive pipelines to maintain their reactive nature, and we use exceptions for imperative code paths. As always, the source code for this tutorial is available on GitHub.

       

1. Introduction

Traditional frameworks, while robust, often introduced complexities that challenged agility. Modern development demands frameworks that aren’t just powerful but nimble. Lightweight frameworks, including Light-4J, adopt a minimalistic design philosophy. They focus on providing essential features without unnecessary complexities, thereby reducing the learning curve for developers and prioritizing swift development cycles.

Light-4J is a cutting-edge Java framework that revolutionizes development by combining agility and performance. It embraces modern development paradigms, aligning with the principles of microservices and catering to the needs of today’s dynamic software architecture.

In this tutorial, we’ll delve into its core philosophy, key features, and architectural concepts. We’ll dissect what makes it lightweight and how this quality translates into enhanced development speed and resource efficiency.

Finally, we’ll uncover how it aligns with contemporary development needs by generating a ready-to-use RESTful API project.

2. What Is Light-4J?

The Light platform offers a variety of frameworks tailored for developing diverse API styles or microservices, depending on the contract specifications. Light-4J is a part of the Light platform designed to build cloud-native Web apps and APIs with different options.

It’s a cutting-edge, open-source microservices framework for Java developers, designed to streamline the development and deployment of scalable, lightweight microservices architectures. With a focus on simplicity, efficiency, and optimal performance, Light-4J empowers developers to build robust, modular applications that can seamlessly adapt to the demands of modern software development.

One of the important characteristics of Light-4J is the prioritization of addressing cross-cutting concerns in cloud-native services by embedding a gateway within its frameworks. This gateway seamlessly manages various aspects of the request/response chain. The functionalities are encapsulated into plugins or middleware handlers and are integrated into the framework through an inversion of control (IoC) service during server initialization.

Importantly, developers have the flexibility to enable, disable, or modify the behavior of these plugins through configurations. This design philosophy empowers developers to focus solely on writing business logic, abstracting away the complexities of managing cross-cutting concerns.

Developers can quickly prototype, iterate, and deploy applications, promoting agility in responding to changing requirements and market demands. Moreover, Light-4J reduces the production operation cost by fulfilling millions of requests per second. This results in lower memory consumption and faster execution, which is crucial for optimizing application performance.

3. Features of Light-4J

Let’s examine the core features of Light-4J:

• Microservices Architecture: Light-4J is architectured with microservices in mind, allowing developers to effortlessly build, deploy, and manage independent and scalable microservices, thus promoting flexibility, agility, and easier maintenance.
• Asynchronous and Non-blocking Communication: It harnesses asynchronous and non-blocking communication patterns. This results in improved responsiveness, as the framework efficiently handles concurrent requests, making it suitable for applications with high concurrency requirements.
• Decentralized Data Management: Unlike monolithic architectures, Light-4J promotes a decentralized approach to data management. Each microservice manages its own data, offering flexibility in choosing appropriate data storage solutions tailored to specific service needs.
• High Performance and Low Latency: Light-4J is engineered for high performance and low latency. By leveraging asynchronous processing and a minimalist design, it ensures faster response times, meeting the expectations for speed and efficiency in modern applications.
• Performance Optimization Techniques: Light-4J offers robust caching strategies to enhance application speed and efficiency. Moreover, the framework includes features for load balancing, ensuring applications can scale seamlessly to meet growing demands.
• Security Middleware: It seamlessly integrates security middleware for robust authentication and authorization, ensuring the protection of microservices and sensitive data. Additionally, it provides middleware for effective logging and monitoring, offering insights into application behavior and performance.
• Customization Capabilities: Light-4J features a powerful plugin system that enables developers to extend its functionality. This modularity facilitates customization, allowing the integration of additional features or third-party plugins tailored to specific project requirements.
• Comprehensive Documentation and Community Support: It also boasts comprehensive documentation, tutorials, and learning paths. Developers can access a wealth of resources that help them understand the framework, implement best practices, and troubleshoot issues.
• Community: Moreover, Light-4J benefits from a vibrant and active developer community. Engaging with this community provides valuable insights, support, and collaborative opportunities for developers working with the framework.

4. Design Principles

Light-4J is guided by several design principles that shape its development and contribute to its effectiveness as a microservices framework. These design principles empower Light-4J to provide a lightweight, efficient, and flexible platform for building microservices in Java. Let’s see some of the key design principles guiding Light-4J development.

Light-4J is specifically designed to cater to the demands of microservices architecture. Therefore, it must excel in several key areas simultaneously. These include achieving high throughput to efficiently handle a large volume of requests, maintaining low latency to ensure quick response times, and being lightweight to minimize resource consumption.

Additionally, Light-4J effectively addresses various cross-cutting concerns inherent in microservices, such as routing, security, logging, and monitoring, while maintaining optimal performance. This multifaceted approach is essential for enabling the seamless development and deployment of microservices-based applications with Light-4J.

Underpinning Light-4J is the JBoss Undertow HTTP server, renowned for its robustness and efficiency. By leveraging this foundation, it inherits the reliability and performance benefits of Undertow, further enhancing its capabilities in handling HTTP requests and responses.

Additionally, Light-4J minimizes dependencies on third-party libraries, adhering to a minimalist approach that enhances stability, security, and ease of maintenance.

4.1. Design-First Approach

Light-4J fundamentally adopts a design-first approach, prioritizing the careful consideration and definition of API contracts and specifications before any actual implementation. By embracing the design-first approach, Light-4J encourages us to meticulously plan and document the desired functionality and behavior of the APIs upfront. This involves leveraging industry-standard specifications such as OpenAPI or AsyncAPI to define the API contract in a machine-readable format.

These specifications serve as a blueprint for the API, detailing its endpoints, request and response payloads, authentication requirements, and other pertinent information. Moreover, it promotes collaboration and alignment between different stakeholders involved in the development process.

Additionally, the design-first approach facilitates the automatic generation of code and documentation based on the API specification. This streamlines the development process, as developers can use tools like the Light-4J code generator to scaffold the initial project structure, generate boilerplate code for API endpoints, and automatically generate API documentation from the API contract. We’ll understand more about this in the upcoming sections.

4.2. Security-First Approach

Light-4J also prioritizes security as a foundational aspect of its design philosophy, adopting a “security-first” approach. This ensures that the applications built on the framework are robustly protected against potential threats and vulnerabilities. Central to this approach is the seamless integration of the OAuth2 protocol for authentication and authorization. This enables the easy implementation of secure authentication and authorization mechanisms for our applications.

Furthermore, Light-4J leverages its embedded distributed gateway to facilitate distributed verification of OAuth2 tokens across a network of services. The distributed gateway acts as a centralized authentication and authorization hub, intercepting incoming requests and validating OAuth2 tokens before allowing access to protected resources. This distributed approach to token verification ensures consistent and reliable security enforcement across all services in a microservices architecture.

5. Setting up Our Development Environment With Light-4J

Setting up a robust development environment is a crucial step in leveraging the capabilities of Light-4J for microservices development. This process involves installing and configuring the framework, defining a project structure that aligns with best practices, and integrating Light-4J seamlessly into our workflow.

Light-4J is compatible with Java. Light-4J v1.5.x and v1.6.x versions are production-ready and are dependent on Java 8, while v2.0.x is built on Java 11. So, having JDK 8 or JDK 11 on our machine is essential for Light-4J.

To get started with Light-4J, we have two options: using the light-codegen generator or starting from an example project.

5.1. Using the light-codegen Generator

We can use the light-codegen tool to facilitate project scaffolding for all frameworks available within Light. It’s powered by the Rocker template engine and can serve both as a utility and as a web service for project scaffolding. It encourages users to essentially create a service contract specification before coding and then scaffold a project based on the designed specification. We can use it in various ways, including command-line, Docker, scripting, and Web UI.

Let’s understand the use of this generator for building a basic REST API project with Light-4J and OpenAPI 3.0.

First, let’s create a base directory and navigate inside it:

$ mkdir baseDir
$ cd baseDir

To start with, we can clone the light-codegen repository into baseDir:

$ git clone git@github.com:networknt/light-codegen.git

Similarly, we can clone the model-config repository, a configuration project for the code generation tool, into the baseDir:

$ git clone git@github.com:networknt/model-config.git

This project contains model definitions and configuration files for frameworks such as light-rest-4j, light-hybrid-4j-server, light-hybrid-4j-service, and light-graphql-4j.

Next, we need to change into the light-codegen directory and build the project:

$ cd light-codegen
$ mvn install -DskipTests

Once the build finishes, we can get back to the baseDir. Then, we can execute the CLI tool that generates the sample PetStore REST API project based on the OpenAPI 3.0 specification. The newly generated project will contain the configuration file for staging of the request-response chain:

$ java -jar light-codegen/codegen-cli/target/codegen-cli.jar \ 
  -f openapi \
  -o light-example-4j/Rest/openAPI/petstore \
  -m model-config/rest/openapi/petstore/1.0.0/openapi.yaml \
  -c model-config/rest/openapi/petstore/1.0.0/config.json

Let’s break down the meanings of these parameters and options:

• -f (framework) – REST framework specification type for the generator
• -o (output) – The target directory for the generated project
• -m (model) – IDL specifications with request and response format for each REST API
• -c (config) – The configuration file that provides details like HTTP ports, packages, and name of the project to be generated

Thus, on successful execution of the above command, we’ll have our new petstore project generated in a new light-example-4j folder in our baseDir:

..... A project has been generated successfully in light-example-4j/Rest/openAPI/petstore folder. Have fun!!!

Finally, we can change to the petstore directory in the newly generated light-example-4j, and launch the project to access its REST APIs:

$ cd light-example-4j/Rest/openAPI/petstore
$ mvn install exec:exec

This will start the HTTPS server on the 8443 port. Thus, we can verify if the REST service is up by hitting the API:

https://127.0.0.1:8443/v1/pets

This will print all the pets:

[{"id":1,"name":"catten","tag":"cat"},{"id":2,"name":"doggy","tag":"dog"}]

We can also access a specific pet with its id:

https://127.0.0.1:8443/v1/pets/1

This will simply return:

{"id":1,"name":"catten","tag":"cat"}

Thus, we can easily manipulate the ready-made configurations and specifications according to our needs and develop our framework on top of Light-4J.

The other way to generate scaffolded projects locally is by invoking light-codegen through the Java command line. We can download the codegen-cli.jar from the release page, place it into our working directory, and run it through the command line.

Finally, we can refer to the light-codegen tutorial for step-by-step guidelines to develop various other API frameworks.

5.2. Starting From an Example Project

The light-example-4j repository contains various example APIs based on various features of the Light-4J framework. We can use these to build and develop our own frameworks on top of Light-4J.

We can directly clone the light-example-4J repository from GitHub to our local machine:

$ git clone git@github.com:networknt/light-example-4j.git

Once we clone the repository, we can choose any available projects according to our use case. For example, to build a RESTful API with the OpenAPI 3.0 specification, we change to the below directory within the cloned repository:

$ cd light-example-4j/rest/openapi

Otherwise, we can also build with Swagger 2.0 and launch a specific project to access its REST APIs as we discussed above:

$ cd light-example-4j/rest/swagger

Similarly, we can get started with many other available frameworks according to our needs.

Also, we can refer to various tutorials that explain step-by-step processes on how to use each component of the Light framework based on our needs.

6. Conclusion

Light-4J is a modern Java framework designed for microservices development, emphasizing agility, performance, and scalability. Its lightweight design philosophy ensures simplicity and efficiency, while its microservices architecture promotes flexibility and easier maintenance. With features like asynchronous communication and a security-first approach, Light-4J empowers developers to build robust applications seamlessly.

In this article, we discussed various features and design principles of Light-4J. We also understood how to use the light-codegen tool to quickly scaffold a REST API project.

As Light-4J continues to evolve, we can expect new features and enhancements, making it a preferred choice for building next-generation microservices architectures.

       

1. Introduction

In this tutorial, we’ll go over how to rescale an image using basic Java APIs. We’ll show how to load and save the image from/to a file and explain some technical aspects of the rescaling process.

2. Loading an Image in Java

For this tutorial, we’ll use a simple JPG image file. We’ll load it using the ImageIO API bundled with the basic Java SDK. This API has a few preset ImageReaders for formats such as JPEG and PNG. ImageReaders know how to read their respective image formats and get a bitmap from an image file.

The method we’ll be using is the read method from ImageIO. There are a few overloads of this method, but we’ll go with the simplest one:

BufferedImage srcImg = ImageIO.read(new File("src/main/resources/images/sampleImage.jpg"));

As we can see, the read() method provides a BufferedImage object, which is the primary Java representation of an image bitmap.

3. Rescaling the Image

Before we rescale the loaded image, we have to do some preparation.

3.1. Creating a Destination Image

First, we have to create a new BufferedImage object representing the scaled image in memory, also called the destination image. Since we’re looking to rescale, it means that the resulting image will have a different width and height from the original.

We must set the scaled sizes in the new BufferedImage:

float scaleW = 2.0f, scaleH = 2.0f;
int w = srcImg.getWidth() * (int) scaleW;
int h = srcImg.getHeight() * (int) scaleH;
BufferedImage dstImg = new BufferedImage(w, h, srcImg.getType());

As shown in the code, the scaling factor doesn’t need to be the same for width and height. However, they usually are since using different scaling factors gives us distorted results.

The BufferedImage constructor also requires an imageType parameter. This is not to be confused with the image file format (e.g., PNG or JPEG); the image type dictates the color space of the new BufferedImage. The class itself provides static int members for supported values such as BufferedImage.TYPE_INT_RGB and BufferedImage.TYPE_BYTE_GRAY for color and gray images, respectively. In our case, we’ll use the same type as the source image since we’re only changing the scale.

The next step is to apply a transformation that will bring the source image to our target size.

3.2. Applying an AffineTransform

We’ll scale the image by applying a scaling affine transformation. These linear transformations can map points from one 2D plane to another. Depending on the transformation, the destination plane can be a scaled-up and even rotated version of the original plane.

In our case, we’ll only apply scaling. The simplest way to think of this is to take all the points that make up the image and increase the distance between them by scaling the factor.

Let’s create an AffineTransform and its respective operation:

AffineTransform scalingTransform = new AffineTransform();
scalingTransform.scale(scaleW, scaleH);
AffineTransformOp scaleOp = new AffineTransformOp(scalingTransform, AffineTransformOp.TYPE_BILINEAR);

The AffineTransform defines what operation we’ll apply, while the AffineTransformOp defines how it’ll be applied. We create an operation that will use a scalingTransform and apply it using a bilinear interpolation.

The selected interpolation algorithm is determined on a case-by-case basis and dictates how the pixel values of the new image will be chosen. What these interpolation algorithms do and why they’re mandatory are beyond the scope of this article. Understanding them requires knowing why we use these linear transformations and how they apply to 2D images.

Once the scaleOp is ready, we can apply it to the srcImg and put the result in the dstImg:

dstImg = scaleOp.filter(srcImg, dstImg);

Finally, we can save the dstImg to a file so we can view the results:

ImageIO.write(dstImg, "jpg", new File("src/main/resources/images/resized.jpg"));

4. Conclusion

In this article, we learned how to scale an image by an arbitrary scale factor. We showed how to load/save images from/to the file system and how to use Java’s AffineTransform to apply the scaling operation.

       

1. Spring and Java

>> Expressive REST Resources with Java Records and Jakarta REST [blog.payara.fish]

Java Records As DTOs: concise, immutable, readable, expressive, and more secure. Yeah.

>> Debugging Streams with Peek [foojay.io]

Peeking into Java streams on the fly: use cases, potentials for misuse, performance overhead, side effects, and more. Cool.

Also worth reading:

• >> How to Detect Cache Misses Using Observability [foojay.io]
• >> Records for Cleaner and More Expressive Parameterized Tests in JUnit 5 [foojay.io]

Webinars and presentations:

• >> Spring Tips: Hello, Java 22! [spring.io]
• >> High-Performance Java Persistence Newsletter, Issue 61 [vladmihalcea.com]
• >> Java 23: Restoring the Balance with Primitive Patterns – Inside Java Newscast #66 [inside.java]
• >> A Bootiful Podcast: Netflix’s Paul Bakker and Kavitha Srinivasan on scaling Spring Boot and Spring GraphQL [spring.io]
• >> A Decade of JDK Updates in OpenJDK [inside.java]

Time to upgrade:

• >> Quarkus 3.9.2 released – Maintenance release [quarkus.io]

2. Technical & Musings

>> Implementing the Idempotency-Key specification on Apache APISIX [frankel.ch]

Avoid duplicate requests by implementing the idempotency key specification on Apache APISIX

Also worth reading:

• >> The Race to Make Humans Obsolete [pointersgonewild.com]
• >> Creating Seams in a Mainframe’s Batch Pipelines [martinfowler.com]
• >> Event modelling anti-patterns explained [event-driven.io]
• >> 12 Text Tools For Developers [foojay.io]

3. Pick of the Week

>> Introducing Sudo for Windows! [microsoft.com]

       

1. Overview

Oracle released Java 21 on September 19, 2023. It’s the latest Java LTS release after Java 17.

This article will discuss the new features and enhancements added to Java 21.

2. List of JEPs

Let’s talk about the notable enhancements introduced to the language in Java 21 through various Java Enhancement Proposals (JEP).

2.1. Record Patterns (JEP 440)

Record patterns were included in Java 19 and Java 20 as preview features, and Java 21 further refines this feature.

This JEP extends the existing pattern-matching feature to destructure the record class instances which enables writing sophisticated data queries.  There is also added support for nested patterns for more composable data queries.

Here’s an example:

record Point(int x, int y) {}
    
public static int beforeRecordPattern(Object obj) {
    int sum = 0;
    if(obj instanceof Point p) {
        int x = p.x();
        int y = p.y();
        sum = x+y;
    }
    return sum;
}
    
public static int afterRecordPattern(Object obj) {
    if(obj instanceof Point(int x, int y)) {
        return x+y;
    }
    return 0;
}

We can also use nested record patterns. The following example demonstrates this:

enum Color {RED, GREEN, BLUE}
record ColoredPoint(Point point, Color color) {}

record RandomPoint(ColoredPoint cp) {}
public static Color getRamdomPointColor(RandomPoint r) {
    if(r instanceof RandomPoint(ColoredPoint cp)) {
        return cp.color();
    }
    return null;
}

In the above code snippet, we destructure the ColoredPoint to access the color() method.

2.2. Pattern Matching for switch (JEP 441)

Pattern matching for switch was introduced in JDK 17 and refined in JDK 18, 19, 20, and JDK 21.

The main goal of this feature is to allow patterns in switch case labels, to improve the expressiveness of switch statements and expressions. Besides, there is also an enhancement to handle NullPointerException by allowing a null case label.

Let us explore this with an example:

class Account{
    double getBalance() {
        return 0;
    }
}
class SavingsAccount extends Account {
    double getBalance() {
        return 100;
    }
}
class TermAccount extends Account {
    double getBalance() {
        return 1000;
    } 
}
class CurrentAccount extends Account {
    double getBalance() {
        return 10000;
    } 
}

Before Java 21, we can use the below code to get the balance:

static double getBalanceWithOutSwitchPattern(Account account) {
    double balance = 0;
    if(account instanceof SavingsAccount sa) {
        balance = sa.getBalance();
    }
    else if(account instanceof TermAccount ta) {
        balance = ta.getBalance();
    }
    else if(account instanceof CurrentAccount ca) {
        balance = ca.getBalance();
    }
    return balance;
}

The above code isn’t very expressive. With Java 21, we can leverage patterns in case labels:

static double getBalanceWithSwitchPattern(Account account) {
    double result = 0;
    switch (account) {
        case null -> throw new RuntimeException("Oops, account is null");
        case SavingsAccount sa -> result = sa.getBalance();
        case TermAccount ta -> result = ta.getBalance();
        case CurrentAccount ca -> result = ca.getBalance();
        default -> result = account.getBalance();
    };
    return result;
}

A pattern case label also supports many values. Let us elaborate on this with an example:

static String processInputOld(String input) {
    String output = null;
    switch(input) {
        case null -> output = "Oops, null";
        case String s -> {
            if("Yes".equalsIgnoreCase(s)) {
                output = "It's Yes";
            }
            else if("No".equalsIgnoreCase(s)) {
                output = "It's No";
            }
            else {
                output = "Try Again";
            }
        }
    }
    return output;
}

The above code can be enhanced using Java 21’s when clauses with case labels:

static String processInputNew(String input) {
    String output = null;
    switch(input) {
        case null -> output = "Oops, null";
        case String s when "Yes".equalsIgnoreCase(s) -> output = "It's Yes";
        case String s when "No".equalsIgnoreCase(s) -> output = "It's No";
        case String s -> output = "Try Again";
    }
    return output;
}

2.3. String Literal (JEP 430)

Java offers several mechanisms to compose strings with string literals and expressions. Some of these are String concatenation, StringBuilder class, String class format() method, and the MessageFormat class.

Java 21 introduces the string templates. This complements Java’s existing string literals and text blocks by coupling literal text with template expressions and template processors to produce the desired results.

Let see an example:

String name = "Baeldung";
String welcomeText = STR."Welcome to \{name}";
System.out.println(welcomeText);

The above code snippet prints the text “Welcome to Baeldung“.

In the above text, we have a template processor (STR), a dot character, and a template that contains an embedded expression (\{name}). At runtime, when the template processor evaluates the template expression, it combines the literal text in the template with the values of the embedded expression to produce the result.

The STR is one of the template processors provided by Java and is automatically imported into all Java source files. The other template processors offered by Java are FMT and RAW.

2.4. Virtual Threads (JEP 444)

Virtual threads were originally introduced to the Java language as a preview feature in Java 19, and further refined in Java 20. Java 21 introduced some new changes.

Virtual threads are lightweight threads. One of the main purposes of these threads is to reduce the effort of developing high-concurrent applications. The traditional threads also called the platform threads are thin wrappers around OS threads. One of the major issues with platform threads is that they run the code on the OS thread and capture the OS thread throughout its lifetime. There is a limit on the number of OS threads and this creates a scalability bottleneck.

Like platform threads, a virtual thread is also an instance of java.lang.Thread class but it isn’t tied to a specific OS thread. It runs the code on a specific OS thread but does not capture the thread for an entire lifetime. Therefore, many virtual threads can share OS threads to run their code.

Let us see the use of the virtual thread with an example:

try(var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.rangeClosed(1, 10_000).forEach(i -> {
        executor.submit(() -> {
            System.out.println(i);
            try {
                Thread.sleep(Duration.ofSeconds(1));
            } 
            catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    });
}

In the above code snippet, we’re using the static newVirtualThreadPerTaskExecutor() method. This executor creates a new virtual thread for each task. Therefore, in the above example, we created 10000 virtual threads.

Java 21 introduced two notable changes to the virtual threads:

• Virtual threads now always support thread-local variables.
• Virtual threads are created through the Thread.Builder API are also monitored through their lifetime and observable in the new thread dump

2.5. Sequenced Collections (JEP 431)

In the Java collection framework, no collection type represents a sequence of elements with a defined encountered order.  For instance, List and Deque interfaces define an encounter order, but their common super type Collection doesn’t. In the same way, Set doesn’t define an encounter order, but subtypes such as LinkedHashSet or SortedSet do.

Java 21 introduced three new interfaces to represent sequenced collections, sequenced sets, and sequenced maps.

A sequenced collection is a collection whose elements have a defined encounter order. It has first and last elements, and the elements between them have successors and predecessors.  A sequenced set is a set that is a sequenced collection with no duplicate elements. A sequenced map is a map whose entries have a defined encountered order.

The following diagram shows the retrofitting of the newly introduced interfaces in the collection framework hierarchy:

2.6. Key Encapsulation Mechanism API (JEP 452)

Key encapsulation is a technique to secure symmetric keys using asymmetric keys or public key cryptography.

The traditional approach uses a public key to secure a randomly generated symmetric key. However, this approach requires padding which is difficult to prove secure.

A key encapsulation mechanism (KEM) uses the public key to derive the symmetric key that doesn’t require any padding.

Java 21 has introduced a new KEM API to enable applications to use KEM algorithms.

3. Conclusion

In this article, we discussed a few notable changes delivered in Java 21.

We discussed record patterns, pattern matching for switches, string templates, sequenced collections, virtual threads, string templates, and the new KEM API.

There are other enhancements and improvements spread across JDK 21 packages and classes. However, this article should be a good starting point for exploring Java 21 new features.

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

       

1. Overview

Matrices are fundamental data structures used in various computer science, mathematics, and engineering fields. In some scenarios, we might need to set certain matrix elements to zero based on specific conditions or requirements. In this tutorial, we’ll discuss various approaches to accomplish this task efficiently in Java.

2. Understanding the Problem

Given a matrix, we aim to set the entire row and column of every zero element in the matrix to zero. This operation effectively “zeroes out” rows and columns that contain at least one zero element.

For example, consider the following matrix:

[1, 2, 3]
[4, 0, 6]
[7, 8, 9]

After applying the transformation, the matrix becomes:

[1, 0, 3]
[0, 0, 0]
[7, 0, 9]

3. The Naive Solution

A frequently employed strategy for obtaining the desired outcome is to utilize a simple method of problem-solving, often without emphasizing optimization or efficiency considerations. It’s usually the most obvious way to tackle a problem, but it may not be the most effective or efficient in terms of performance or resource usage.

To solve our problem using a naive approach, we can start by duplicating the input matrix to preserve the original values and then traverse it to detect zero elements.

Upon encountering a zero element, we proceed to zero out the entire corresponding row and column in the copied matrix. Finally, we update the original matrix with the modified values obtained from the copy:

public class SetMatrixToZero {
    static void setZeroesByNaiveApproach(int[][] matrix) {
        int row = matrix.length;
        int col = matrix[0].length;
        int [][] result = new int[row][col];
        for (int i = 0; i<row; i++) {
            for (int j = 0; j < col; j++) {
                result[i][j] = matrix[i][j];
            }
        }
        
        for (int i = 0; i < row; i++) {
            for (int j = 0; j < col; j++) {
                if (matrix[i][j] == 0) {
                    for (int k = 0; k < col; k++) {
                        result[i][k] = 0;
                    }
                    for (int k = 0; k < row; k++) {
                        result[k][j] = 0;
                    }
                }
            }
        }
        for (int i = 0; i < row; i++) {
            for (int j = 0; j < col; j++) {
                matrix[i][j] = result[i][j];
            }
        }
    }
}

While this approach is straightforward, it has a time complexity of $O((mn)\ast (m+n))$, where m is the number of rows and n is the number of columns. Its space complexity is O(m*n). For large matrices, this approach may not be efficient.

Let’s test this approach by executing the below test:

@Test
void givenMatrix_whenUsingSetZeroesByNaiveApproach_thenSetZeroes() {
    int[][] matrix = {
        {1, 2, 3},
        {4, 0, 6},
        {7, 8, 9}
    };
    int[][] expected = {
        {1, 0, 3},
        {0, 0, 0},
        {7, 0, 9}
    };
    SetMatrixToZero.setZeroesByNaiveApproach(matrix);
    assertArrayEquals(expected, matrix);
}

4. The Time Optimized Approach

This approach focuses on improving the time complexity of the solution by using an additional space to store the indices of zero elements in the matrix.

It first traverses the matrix to identify zero elements and stores their row and column indices in separate HashSet. Then, it traverses the matrix again and sets the corresponding rows and columns to zero based on the stored indices:

static void setZeroesByTimeOptimizedApproach(int[][] matrix) {
    int rows = matrix.length;
    int cols = matrix[0].length;
    Set<Integer> rowSet = new HashSet<>();
    Set<Integer> colSet = new HashSet<>();
    for (int i = 0; i < rows; i++) {
        for (int j = 0; j < cols; j++) {
            if (matrix[i][j] == 0) {
                rowSet.add(i);
                colSet.add(j);
            }
        }
    }
    for (int row: rowSet) {
        for (int j = 0; j < cols; j++) {
            matrix[row][j] = 0;
        }
    }
    for (int col: colSet) {
        for (int i = 0; i < rows; i++) {
            matrix[i][col] = 0;
        }
    }
}

This approach has a time complexity of O(m * n) and requires additional space of O(m + n) for storing indices, which can be inefficient for large matrices.

We can validate the above approach through the below test:

@Test
void givenMatrix_whenUsingSetZeroesByTimeOptimizedApproach_thenSetZeroes() {
    int[][] matrix = {
        {1, 2, 3},
        {4, 0, 6},
        {7, 8, 9}
    };
    int[][] expected = {
        {1, 0, 3},
        {0, 0, 0},
        {7, 0, 9}
    };
    SetMatrixToZero.setZeroesByTimeOptimizedApproach(matrix);
    assertArrayEquals(expected, matrix);
}

5. The Optimal Approach

This approach optimizes space complexity by modifying the original matrix in place without using additional space.

It utilizes the matrix’s first row and first column to store information about zero elements. The algorithm first checks if the first row and first column contain any zeros.

Then, it marks zero elements in the first row and first column by setting the corresponding elements to zero. Next, it traverses the matrix (excluding the first row and first column) to mark zero elements in the first row and first column.

Finally, it traverses the first row and first column to update the entire row or column to zero if needed.

We’ll break the above steps into separate helper methods. The below code checks if there is at least one zero in the first row of the matrix:

static boolean hasZeroInFirstRow(int[][] matrix, int cols) {
    for (int j = 0; j < cols; j++) {
        if (matrix[0][j] == 0) {
            return true;
        }
    }
    return false;
}

Similarly, we check if there is at least one zero in the first column of the matrix:

static boolean hasZeroInFirstCol(int[][] matrix, int rows) {
    for (int i = 0; i < rows; i++) {
        if (matrix[i][0] == 0) {
            return true;
        }
    }
    return false;
}

We mark the positions in the matrix where zeros are present by setting corresponding elements in the first row and first column to zero:

static void markZeroesInMatrix(int[][] matrix, int rows, int cols) {
    for (int i = 1; i < rows; i++) {
        for (int j = 1; j < cols; j++) {
            if (matrix[i][j] == 0) {
                matrix[i][0] = 0;
                matrix[0][j] = 0;
            }
        }
    }
}

Next, we set zeroes in rows based on the markings made in the first column of the matrix:

static void setZeroesInRows(int[][] matrix, int rows, int cols) {
    for (int i = 1; i < rows; i++) {
        if (matrix[i][0] == 0) {
            for (int j = 1; j < cols; j++) {
                matrix[i][j] = 0;
            }
        }
    }
}

Similarly, we set zeroes in columns based on the markings made in the first row of the matrix:

static void setZeroesInCols(int[][] matrix, int rows, int cols) {
    for (int j = 1; j < cols; j++) {
        if (matrix[0][j] == 0) {
            for (int i = 1; i < rows; i++) {
                matrix[i][j] = 0;
            }
        }
    }
}

Now, we set all elements in the first row to zero:

static void setZeroesInFirstRow(int[][] matrix, int cols) {
    for (int j = 0; j < cols; j++) {
        matrix[0][j] = 0;
    }
}

We follow a similar approach for the first column:

static void setZeroesInFirstCol(int[][] matrix, int rows) {
    for (int i = 0; i < rows; i++) {
        matrix[i][0] = 0;
    }
}

We merge all the preceding steps and execute them within this method:

static void setZeroesByOptimalApproach(int[][] matrix) {
    int rows = matrix.length;
    int cols = matrix[0].length;
    
    boolean firstRowZero = hasZeroInFirstRow(matrix, cols);
    boolean firstColZero = hasZeroInFirstCol(matrix, rows);
    
    markZeroesInMatrix(matrix, rows, cols);
    
    setZeroesInRows(matrix, rows, cols);
    setZeroesInCols(matrix, rows, cols);
    
    if (firstRowZero) {
        setZeroesInFirstRow(matrix, cols);
    }
    if (firstColZero) {
        setZeroesInFirstCol(matrix, rows);
    }
}

This approach eliminates the need for additional space, resulting in an additional space complexity of O(1). The overall space complexity remains O(m * n).

It accomplishes the intended outcome within the existing matrix and maintains a time complexity of O(m * n), where n represents the number of rows and n signifies the number of columns. This efficiency makes it suitable for handling large matrices.

Let’s write the test to assess this approach:

@Test
void givenMatrix_whenUsingSetZeroesByOptimalApproach_thenSetZeroes() {
    int[][] matrix = {
        {1, 2, 3},
        {4, 0, 6},
        {7, 8, 9}
    };
    int[][] expected = {
        {1, 0, 3},
        {0, 0, 0},
        {7, 0, 9}
    };
    SetMatrixToZero.setZeroesByOptimalApproach(matrix);
    assertArrayEquals(expected, matrix);
}

6. Conclusion

In this tutorial, we explored various methods for setting elements to zero in a matrix. The naive approach aims to achieve the desired outcome without prioritizing optimization or performance. In contrast, the time-optimized approach reduces time complexity by utilizing extra space.

However, the optimal approach enhances both time complexity and doesn’t necessitate any additional space, making it the better choice out of all the above approaches. It’s important to acknowledge that there could be several other optimal solutions to this problem.

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