1. Overview

Java 8’s CompletableFuture is well-suited to handling asynchronous computation. For instance, a web client may employ CompletableFuture when making a server call. It’s easy to get started and handle an individual CompletableFuture response. However, it’s not immediately clear how to collect the results of multiple CompletableFuture executions while also handling exceptions.

In this tutorial, we’ll develop a simple mock microservice client that returns a CompletableFuture, and see how to call it multiple times to generate a summary of successes and failures.

2. An Example Microservice Client

For our example, let’s write a simple microservice client that’s responsible for creating a resource and returning that resource’s identifier.

We’ll declare a simple interface, MicroserviceClient, that we can mock out (using Mockito) in our unit test:

interface MicroserviceClient {
    CompletableFuture<Long> createResource(String resourceName);
}

Unit testing CompletableFuture comes with its own challenges, but testing a single call to MicroserviceClient would be straightforward. Rather than detailing that here, let’s move on to handling multiple client calls that can throw an exception.

3. Combining Multiple Calls to Microservice

Let’s start by creating a unit test and declaring a mock of our MicroserviceClient that returns a successful response for an input of “Good Resource” and throws an exception for an input of “Bad Resource“:

@ParameterizedTest
@MethodSource("clientData")
public void givenMicroserviceClient_whenMultipleCreateResource_thenCombineResults(List<String> inputs,
  int expectedSuccess, int expectedFailure) throws ExecutionException, InterruptedException {
    MicroserviceClient mockMicroservice = mock(MicroserviceClient.class);
    when(mockMicroservice.createResource("Good Resource"))
      .thenReturn(CompletableFuture.completedFuture(123L));
    when(mockMicroservice.createResource("Bad Resource"))
      .thenReturn(CompletableFuture.failedFuture(new IllegalArgumentException("Bad Resource")));
}

We’ll make this a parameterized test and pass in varying sets of data with a MethodSource. We’ll need to create a static method to supply our test with a Stream of JUnit Arguments:

private static Stream<Arguments> clientData() {
    return Stream.of(
      Arguments.of(List.of("Good Resource"), 1, 0),
      Arguments.of(List.of("Bad Resource"), 0, 1),
      Arguments.of(List.of("Good Resource", "Bad Resource"), 1, 1),
      Arguments.of(List.of("Good Resource", "Bad Resource", "Good Resource", "Bad Resource", 
        "Good Resource"), 3, 2)
    );
}

This creates four test executions that pass in a List of inputs and the expected count of successes and failures.

Next, let’s return to our unit test and use the test data to call MicroserviceClient and collect each resulting CompletableFuture into a List:

List<CompletableFuture<Long>> clientCalls = new ArrayList<>();
for (String resource : inputs) {
    clientCalls.add(mockMicroservice.createResource(resource));
}

Now, we have the core part of our problem: a List of CompletableFuture objects that we need to complete and collect the results of, while handling any exceptions we encounter.

3.1. Handling Exceptions

Before getting into how we’ll complete each CompletableFuture, let’s define a helper method for handling exceptions. We’ll also define and mock out a Logger to mimic real-world error handling:

private final Logger logger = mock(Logger.class);
private Long handleError(Throwable throwable) {
    logger.error("Encountered error: " + throwable);
    return -1L;
}
interface Logger {
    void error(String message);
}

The helper method simply “logs” the error message and returns -1, which we’re using to designate an invalid resource.

3.2. Completing a CompletableFuture With Exception Handling

Now, we need to complete all of the CompletableFuture and handle any exceptions appropriately. We can do this by leveraging a few tools CompleteableFuture provides us with:

• exceptionally(): takes a function to execute if the CompletableFuture completes with an exception
• join(): returns the result of the CompletableFuture once it completes

Then, we can define a helper method for completion of a single CompletableFuture:

private Long handleFuture(CompletableFuture<Long> future) {
    return future
      .exceptionally(this::handleError)
      .join();
}

Notably, we’re using exceptionally() to handle any exceptions that the MicroserviceClient calls could throw via our handleError() helper method. Finally, we’re calling join() on the CompletableFuture to wait for completion of the client call and return its resource identifier.

3.3. Handling a List of CompletableFuture

Returning to our unit test, we can now leverage our helper methods along with Java’s Stream API to create a simple statement that resolves all of the client calls:

Map<Boolean, List<Long>> resultsByValidity = clientCalls.stream()
  .map(this::handleFuture)
  .collect(Collectors.partitioningBy(resourceId -> resourceId != -1L));

Let’s break down this statement:

• We map each CompletableFuture into the resulting resource identifier using our handleFuture() helper method
• We use Java’s Collectors.partitioningBy() utility to split the resulting resource identifiers into separate lists based on validity

We can easily verify our test by using an assertion on the size of the partitioned Lists, as well as checking calls to our mocked Logger:

List<Long> validResults = resultsByValidity.getOrDefault(true, List.of());
assertThat(validResults.size()).isEqualTo(successCount);
List<Long> invalidResults = resultsByValidity.getOrDefault(false, List.of());
assertThat(invalidResults.size()).isEqualTo(errorCount);
verify(logger, times(errorCount))
  .error(eq("Encountered error: java.lang.IllegalArgumentException: Bad Resource"));

Running the test, we can see our partitioned lists match what we expect.

4. Conclusion

In this article, we learned how to handle completing a collection of CompletableFuture. If necessary, we could easily extend our approach to use more robust error handling or complex business logic.

As always, all of the code for the article can be found over on GitHub.

       

1. Introduction

The Gson library developed by Google is quite a good choice for serialization and deserialization of Java objects to and from JSON format. Besides, we typically come across the problem that Gson shows integers as floating-point numbers while serializing objects.

In this tutorial, we’ll see why integers are considered floating-point numbers. Moreover, we’ll provide a solution to prevent Gson from doing that.

2. Problem Definition

Gson serializes Java objects to JSON. By default, Gson serializes integers as floating-point numbers for a more accurate representation. Here’s a simple example:

public String jsonString= "[{\"id\":4077395,\"field_id\":242566,\"body\":\"\"}, " +
  "{\"id\":4077398,\"field_id\":242569,\"body\":[[273019,0],[273020,1],[273021,0]]}, " +
  "{\"id\":4077399,\"field_id\":242570,\"body\":[[273022,0],[273023,1],[273024,0]]}]";

Here, we declared a JSON string called jsonString that represents an array of objects. This JSON array has different fields, such as id, field_id, and body.

Now, we’ll use the Gson library for JSON string deserialization into a list of Hashtable<String, Object> objects.

ArrayList<Hashtable<String, Object>> responses;
Type ResponseList = new TypeToken<ArrayList<Hashtable<String, Object>>>() {}.getType();
responses = new Gson().fromJson(jsonString, ResponseList);

Here, we declare an ArrayList named responses to contain elements of type Hashtable with String keys and Object values. Moreover, we utilize the Gson library for deserializing the jsonString into a list of Hashtables.

Finally, we use the TypeToken to get generic type information during deserialization.

The responses will be formatted as follows:

[{
    body = ,
    field_id = 242566.0,
    id = 4077395.0
}, {
    body = [
        [273019.0, 0.0],
        [273020.0, 1.0],
        [273021.0, 0.0]
    ],
    field_id = 242569.0,
    id = 4077398.0
}, {
    body = [
        [273022.0, 0.0],
        [273023.0, 1.0],
        [273024.0, 0.0]
    ],
    field_id = 242570.0,
    id = 4077399.0
}]

Note that the Gson represents integers as floating-point numbers.

3. Default Number Strategy in Gson

Gson’s default number strategy aims to strike a balance between accuracy and flexibility when representing numeric values. The decision to use floating-point numbers for integers is based on the idea that JSON lacks explicit support for distinguishing between integer and floating-point types. Therefore, Gson opts for a default strategy that ensures the preservation of precision in numeric values.

However, this default behavior may not align with specific requirements or preferences, especially when dealing with scenarios where integers should remain integers in the JSON representation.

4. Using setObjectToNumberStrategy() Method

Using the Gson method setObjectToNumberStrategy(), we can thoroughly control the functionalities of the object-to-number conversion mechanism during the deserialization process.

Let’s explore this capability through an illustrative example:

public static String expectedOutput ="[{body=, field_id=242566, id=4077395}, " +
  "{body=[[273019, 0], [273020, 1], [273021, 0]], field_id=242569, id=4077398}, " +
  "{body=[[273022, 0], [273023, 1], [273024, 0]], field_id=242570, id=4077399}]";
@Test
public void givenJsonString_whenUsingsetObjectToNumberStrategyMethod_thenValidateOutput() {
    Gson gson = new GsonBuilder()
      .setObjectToNumberStrategy(ToNumberPolicy.LONG_OR_DOUBLE)
      .create();
    ArrayList<Hashtable<String, Object>> responses = gson.fromJson(jsonString,
      new TypeToken<ArrayList<Hashtable<String, Object>>>() {}.getType());
    assertEquals(expectedOutput, responses.toString());
}

Here, the use of the setObjectToNumberStrategy() method enables us to set up a strategy such as ToNumberPolicy.LONG_OR_DOUBLE for Gson to direct its behavior in regard to numeric values. Finally, we verify the conversion process using the assertEquals() method.

Moreover, the ToNumberPolicy enum in Gson supports various strategies for handling numeric values. Besides ToNumberPolicy.LONG_OR_DOUBLE, which we used in the example, other strategies include:

• ToNumberPolicy.DOUBLE_ONLY: converts all numeric values to double during deserialization
• ToNumberPolicy.LONG_ONLY: converts all numeric values to long during deserialization
• ToNumberPolicy.DEFAULT: retains Gson’s default behavior, representing integers as floating-point numbers

5. Conclusion

In this article, we discuss an issue encountered with Gson: integers are automatically converted to floating-point numbers during the serialization process. To resolve this problem, we use the setObjectToNumberStrategy() method.

As always, the complete code samples for this article can be found over on GitHub.

       

1. Spring and Java

>> Emulating C# LINQ in Java using Code Reflection [openjdk.org]

Java’s LINQ Inspiration: unleashing Code Reflection Power, Emulating the LINQ in Java.

>> FetchType: Lazy/Eager loading for Hibernate & JPA [thorben-janssen.com]

Mastering JPA Fetch Types: a comprehensive guide to entity mappings and performance optimization.

>> Hibernate StatelessSession JDBC Batching [vladmihalcea.com]

And, still on the persistence track – optimizing Hibernate: exploring StatelessSession and JDBC Batching.

Also worth reading:

• >> JDK 22 G1/Parallel/Serial GC changes [tschatzl.io]
• >> Extension Functions in Kotlin [reflectoring.io]
• >> Managing Throughput with Virtual Threads – Sip of Java [inside.java]
• >> This Week in Spring – February 6th [spring.io]
• >> Automatic differentiation of Java code using Code Reflection [openjdk.org]
• >> Sorting Text in Java, How Complicated Can It Be? [foojay.io]
• >> Writing Integration Tests for Spring Boot Web Applications: Build Setup [petrikainulainen.net]
• >> Pinterest Open-Sources a Production-Ready PubSub Java Client for Kafka, Flink, and MemQ [infoq.com]
• >> Optimizing Java for Modern Hardware: The Continuous Evolution of the Vector API [infoq.com]

Webinars and presentations:

• >> Data Oriented Programming in Java 21 [inside.java]
• >> Spring Tips: Spring Boot Testjars [spring.io]
• >> Spring Tips: Spring AI [spring.io]
• >> A Bootiful Podcast: Dr. Venkat Subramaniam, on the latest in Java [spring.io]
• >> Java 21 and Beyond: A Roadmap of Innovations [inside.java]

Time to upgrade:

• >> Spring Boot 3.2 and Spring Framework 6.1 Add Java 21, Virtual Threads, and CRaC [infoq.com]
• >> Hibernate ORM 6.4.4.Final released [in.relation.to]
• >> Spring Tools 4.21.1 released [spring.io]
• >> Hibernate Search 7.1.0.CR1 is out [in.relation.to]

2. Technical & Musings

>> Apache Pekko: Simplifying Concurrent Development With the Actor Model [infoq.com]

Meet Apache Pekko: Taking Advantage of Actor Model for Scalability and Resilience in Distributed Systems

Also worth reading:

• >> Kicking the Tires of Docker Scout [foojay.io]
• >> Announcing Emmett! Take your event-driven applications back to the future! [event-driven.io]
• >> DTrace Revisited: Advanced Debugging Techniques [foojay.io]

3. Pick of the Week

>> Empower your Jakarta EE development with Payara Server [payara.fish]

       

1. Introduction

Privacy and data security are important elements of software development. Masking sensitive details such as the user’s email address and phone number is usually one procedure used to safeguard user information and prevent its disclosure.

In this tutorial, we’ll investigate how to mask email addresses and phone numbers in Java.

2. Masking Email Addresses

2.1. Using String Manipulation

String manipulation is one of the ways to hide an email by editing the characters and replacing a few with asterisks. Here’s a simple Java code snippet demonstrating this approach:

String email = "testemailaddress@example.com";
String expectedMaskedEmail = "te**************@example.com";
@Test
public void givenEmailAddress_whenUsingStringManipulation_thenMaskEmail() {
    int atIndex = email.indexOf('@');
    String repeatedString = IntStream.range(0, atIndex - 2).mapToObj(i -> "*").collect(Collectors.joining());
    String maskedPart = email.substring(0, atIndex - repeatedString.length()) + repeatedString;
    String maskedEmail = maskedPart + email.substring(atIndex);
    assertEquals(expectedMaskedEmail, maskedEmail);
}

In the given example, we first find the index of the “@” character in the email address. Then, we generate a string of asterisks with a length equal to atIndex-2 using Java’s Stream API and string operations. Note that we subtract 2 digits from the atIndex to make the first two digits of the email.

The maskedPart of the email is generated by combining the characters before the “@” symbol with the generated string of asterisks in the context of the provided Java code.

The email address is then obtained by concatenating the maskedPart and the generated asterisks. Finally, we use the assertEquals() method to verify that the maskedEmail is the same as the expectedMaskedEmail.

2.2. Using Regular Expressions

Another method is to implement regular expressions to conceal the email address. Here’s an example:

@Test
public void givenEmailAddress_whenUsingRegex_thenMaskEmail() {
    int atIndex = email.indexOf('@');
    String regex = "(.{2})(.*)(@.*)";
    String repeatedAsterisks = "*".repeat(atIndex - 2);
    String maskedEmail = email.replaceAll(regex, "$1" + repeatedAsterisks + "$3");
    assertEquals(expectedMaskedEmail, maskedEmail);
}

In the above test method, we first determine the index of the “@” symbol in the email using the indexOf() method. Then, we use the regular expression regex “(.{2})(.*)(@.*)” to capture three groups: the first two characters, the characters between them and the “@” symbol, and the characters following the “@“.

Subsequently, the variable repeatedAsterisks is assigned a string of asterisks with a length corresponding to atIndex -2. Finally, the replaceAll() method applies the regex pattern, replacing the middle part of the email with the generated asterisks.

3. Masking Phone Numbers

3.1. Using String Manipulation

We can also mask phone numbers by performing some character manipulations. Here’s an example:

String phoneNumber = "+1234567890";
String expectedMaskedPhoneNumber = "+******7890";
@Test
public void givenPhoneNumber_whenUsingStringManipulation_thenMaskPhone() {
    String maskedPhoneNumber = phoneNumber.replaceAll("\\d(?=\\d{4})", "*");
    assertEquals(expectedMaskedPhoneNumber, maskedPhoneNumber);
}

Here, we pass the regular expression “\\d(?=\\d{4})” to the replaceAll() method, aiming to identify and replace all numeric digits that are followed by four more digits with asterisks.

3.2. Using Regular Expressions

Similarly to the method used for masking email addresses, regular expressions can be implemented to hide the phone numbers properly. Here’s a Java code snippet demonstrating this method:

@Test
public void givenPhoneNumber_whenUsingRegex_thenMaskPhone() {
    int lastDigitsIndex = phoneNumber.length() - 5;
    String regex = "(\\+)(\\d+)(\\d{4})";
    String repeatedAsterisks = "*".repeat(Math.max(0, lastDigitsIndex));
    String maskedPhoneNumber = phoneNumber.replaceAll(regex, "$1" + repeatedAsterisks + "$3");
    assertEquals(expectedMaskedPhoneNumber, maskedPhoneNumber);
}

In the above code snippet, we define a regular expression regex “(\\+)(\\d+)(\\d{4})” that captures three groups: the plus sign, the leading digits, and the last four digits.

Subsequently, we generate a string repeatedAsterisks of repeated asterisks based on the calculated lastDigitsIndex. Then,  we use the replaceAll() method to apply the regex pattern, replacing the middle digits with asterisks.

4. Conclusion

In conclusion, the masking of sensitive information is critical for protecting user privacy and adhering to data security regulations. Hence, we see in this tutorial how to utilize mechanisms such as string manipulation and regular expressions to mask email addresses and phone numbers.

As always, the complete code samples for this article can be found over on GitHub.

       

1. Overview

We often use logging to document meaningful steps and valuable information during the program execution. It allows us to record data we can use later to debug and analyze the code.

Additionally, Aspect-Oriented Programming (or AOP for short) is a paradigm that lets us segregate cross-cutting concerns, such as transaction management or logging, throughout the application without cluttering the business logic.

In this tutorial, we’ll learn how to implement logging using the AOP and Spring framework.

2. Logging Without AOP

When it comes to logging, we usually put logs at the beginning and the end of the methods. This way, we can easily track the application execution flow. In addition, we can capture the values being passed to specific methods and the values they return.

To demonstrate, let’s create the GreetingService class with the greet() method:

public String greet(String name) {
    logger.info(">> greet() - {}", name);
    String result = String.format("Hello %s", name);
    logger.info("<< greet() - {}", result);
    return result;
}

Even though the implementation above seems like a standard solution, logging statements can feel like unnecessary clutter in our code.

Furthermore, we introduced additional complexity to our code. Without logging, we could rewrite this method as a one-liner:

public String greet(String name) {
    return String.format("Hello %s", name);
}

3. Aspect-Oriented Programming

As the name suggests, Aspect-Oriented Programming focuses on aspects rather than objects and classes. We use AOP to implement additional functionality for specific application parts without modifying their current implementations.

3.1. AOP Concepts

Before we dive in, let’s examine the basic AOP concepts at a very high level.

• Aspect: The cross-cutting concern or the functionality we’d like to apply throughout the application.
• Join Point: The point of the application flow where we want to apply an aspect.
• Advice: The action that should be executed at a specific join point.
• Pointcut: Collection of join points where an aspect should be applied.

Furthermore, it’s worth noting that Spring AOP only supports join points for method execution. We should consider using compile-time libraries such as AspectJ to create aspects for fields, constructors, static initializers, etc.

3.2. Maven Dependency

To use Spring AOP, let’s add the spring-boot-starter-aop dependency in our pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

4. Logging With AOP

One way to implement AOP in Spring is by using a Spring bean annotated with the @Aspect annotation:

@Aspect
@Component
public class LoggingAspect {
}

The @Aspect annotation serves as a marker annotation, so Spring won’t automatically treat it as a component. To indicate it should be a bean managed by Spring and detected through component scanning, we also annotate the class with the @Component annotation.

Next, let’s define a pointcut. Simply put, pointcuts allow us to specify which join point execution we want to intercept with an aspect:

@Pointcut("execution(public * com.baeldung.logging.*.*(..))")
private void publicMethodsFromLoggingPackage() {
}

Here, we defined a pointcut expression that includes only public methods from the com.baeldung.logging package.

Moving forward, let’s see how to define the advice to log the start and the end of the method execution.

4.1. Using Around Advice

We’ll start with the more general advice type – the Around advice. It allows us to implement custom behavior before and after the method invocation. Moreover, with this advice, we can decide whether to proceed with the specific join point, return a custom result, or throw an exception.

Let’s define the advice using the @Around annotation:

@Around(value = "publicMethodsFromLoggingPackage()")
public Object logAround(ProceedingJoinPoint joinPoint) throws Throwable {
    Object[] args = joinPoint.getArgs();
    String methodName = joinPoint.getSignature().getName();
    logger.info(">> {}() - {}", methodName, Arrays.toString(args));
    Object result = joinPoint.proceed();
    logger.info("<< {}() - {}", methodName, result);
    return result;
}

The value attribute associates this Around advice with the previously defined pointcut. The advice runs around method executions matched by the publicMethodsFromLoggingPackage() pointcut signature.

The method accepts a ProceedingJoinPoint parameter. It’s a subclass of the JoinPoint class, allowing us to call the proceed() method to execute the next advice (if it exists) or the target method.

We call the getArgs() method on the joinPoint to retrieve the array of method arguments. Additionally, we use the getSignature().getName() method to get the name of the method we’re intercepting.

Next, we call the proceed() method to execute the target method and retrieve the result.

Finally, let’s call the greet() method we mentioned earlier:

@Test
void givenName_whenGreet_thenReturnCorrectResult() {
    String result = greetingService.greet("Baeldung");
    assertNotNull(result);
    assertEquals("Hello Baeldung", result);
}

After running our test, we can see the following result in our console:

>> greet() - [Baeldung]
<< greet() - Hello Baeldung

5. Using the Least Invasive Advice

When deciding which type of advice to use, it’s recommended that we use the least powerful advice that serves our needs. If we choose a general advice, such as Around advice, we’re more prone to potential errors and performance issues.

That’s to say, let’s examine how to accomplish the same functionality, but this time using the Before and After advices. Unlike Around advice, they don’t wrap the method execution, thus, there’s no need to explicitly call the proceed() method to continue with join point execution. Specifically, we use these types of advice to intercept methods right before or after execution.

5.1. Using Before Advice

To intercept the method before its execution, we’ll create an advice using the @Before annotation:

@Before(value = "publicMethodsFromLoggingPackage()")
public void logBefore(JoinPoint joinPoint) {
    Object[] args = joinPoint.getArgs();
    String methodName = joinPoint.getSignature().getName();
    logger.info(">> {}() - {}", methodName, Arrays.toString(args));
}

Similar to the previous example, we used the getArgs() method to get method arguments and the getSignature().getName() method to get the method name.

5.2. Using AfterReturning Advice

Going further, to add a log after the method execution, we’ll create the @AfterReturning advice that runs if a method execution completes without throwing any exception:

@AfterReturning(value = "publicMethodsFromLoggingPackage()", returning = "result")
public void logAfter(JoinPoint joinPoint, Object result) {
    String methodName = joinPoint.getSignature().getName();
    logger.info("<< {}() - {}", methodName, result);
}

Here, we defined the returning attribute to get the value returned from the method. Additionally, the value we provided in the attribute should match the parameter’s name. The return value will be passed to the advice method as an argument.

5.3. Using AfterThrowing Advice

On the other hand, to log situations when the method invocation completes with an exception, we could use the @AfterThrowing advice:

@AfterThrowing(pointcut = "publicMethodsFromLoggingPackage()", throwing = "exception")
public void logException(JoinPoint joinPoint, Throwable exception) {
    String methodName = joinPoint.getSignature().getName();
    logger.error("<< {}() - {}", methodName, exception.getMessage());
}

This time, instead of the return value, we’ll get the thrown exception in our advice method.

6. Spring AOP Pitfalls

Lastly, let’s discuss some concerns we should consider when working with Spring AOP.

Spring AOP is a proxy-based framework. It creates proxy objects to intercept method calls and apply logic defined in advice. This can negatively impact the performance of our application.

To reduce the effect of AOP on performance, we should consider using AOP only when necessary. We should avoid creating aspects for isolated and infrequent operations.

Finally, if we use AOP for development purposes only, we can create it conditionally, for instance, only if a specific Spring profile is active.

7. Conclusion

In this article, we learned how to perform logging using Spring AOP.

To sum up, we examined how to implement logging using Around advice as well as Before and After advice. We also explored why it’s important to use the least powerful advice to fit our needs. Finally, we addressed some potential issues Spring AOP brings to the table.

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

       

1. Introduction

Apache Kafka is a distributed streaming platform that allows us to publish and subscribe to streams of records, often referred to as messages. Additionally, Kafka headers provide a way to attach metadata to Kafka messages, enabling additional context and flexibility in message processing.

In this tutorial, we’ll delve into commonly used Kafka headers and learn how to view and extract them using Java.

2. Overview of Kafka Headers

Kafka headers represent key-value pairs attached to Kafka messages, offering a means to include supplementary metadata alongside the primary message content.

For example, Kafka headers facilitate message routing by providing data for directing messages to specific processing pipelines or consumers. Moreover, headers are versatile in carrying custom application metadata tailored to the application’s processing logic.

3. Kafka Default Headers

Kafka automatically includes several default headers in messages sent by the Kafka producer. Moreover, these headers offer crucial metadata and context about the message. In this section, we’ll delve into a few commonly used headers and their significance in the realm of Kafka message processing.

3.1. Producer Headers

When messages are produced in Kafka, several default headers are automatically included by the producer, such as:

• KafkaHeaders.TOPIC – This header contains the name of the topic to which the message belongs.
• KafkaHeaders.KEY – If the message is produced with a key, Kafka automatically includes a header named “key” containing the serialized key bytes.
• KafkaHeaders.PARTITION – Kafka adds a header named “partition” to indicate the partition ID to which the message belongs.
• KafkaHeaders.TIMESTAMP – Kafka attaches a header named “timestamp” to each message, indicating the timestamp of when the message was produced by the producer.

3.2. Consumer Headers

Headers prefixed with RECEIVED_ are added by the Kafka consumer upon message consumption to provide metadata about the message’s reception process:

• KafkaHeaders.RECEIVED_TOPIC – This header contains the name of the topic from which the message was received.
• KafkaHeaders.RECEIVED_KEY – This header allows consumers to access the key associated with the message.
• KafkaHeaders.RECEIVED_PARTITION_ID – Kafka adds this header to indicate the ID of the partition to which the message was assigned.
• KafkaHeaders.RECEIVED_TIMESTAMP – This header reflects the time at which the consumer received the message.
• KafkaHeaders.OFFSET – The offset indicates the position of the message in the partition’s log.

4. Consuming Messages With Headers

To begin, we instantiate a KafkaConsumer object. The KafkaConsumer is responsible for subscribing to Kafka topics and fetching messages from them. After instantiating the KafkaConsumer, we subscribe to the Kafka topic from which we want to consume messages. By subscribing to a topic, the consumer can receive messages published on that topic.

Once the consumer subscribes to the topic, we proceed to fetch records from Kafka. During this process, the KafkaConsumer retrieves messages from the subscribed topic, along with their associated headers.

Here’s a code example demonstrating how to consume messages with headers:

@KafkaListener(topics = "my-topic")
public void listen(String message, @Headers Map<String, Object> headers) {
    System.out.println("Received message: " + message);
    System.out.println("Headers:");
    headers.forEach((key, value) -> System.out.println(key + ": " + value));
}

The Kafka listener container invokes the listen() method when receiving a message from the specified topic(s), such as “my-topic“. The @Headers annotation indicates that the parameter should be populated with the headers of the received message.

Below is an example output:

Received message: Hello Baeldung!
Headers:
kafka_receivedMessageKey: null
kafka_receivedPartitionId: 0
kafka_receivedTopic: my-topic
kafka_offset: 123
... // other headers

To access a specific header, we can use the get() method of the headers map, providing the key of the desired header. Below is an example to access the topic name:

String topicName = headers.get(KafkaHeaders.TOPIC);

The topicName should return my-topic.

Additionally, when consuming messages, we can directly extract the headers needed for processing as method parameters if we already know them. This approach offers a more concise and targeted way to access specific header values without iterating through all headers.

Here’s a code example demonstrating how to consume messages with headers, directly extracting specific headers as method parameters:

@KafkaListener(topics = "my-topic")
public void listen(String message, @Header(KafkaHeaders.RECEIVED_PARTITION_ID) int partition) {
    System.out.println("Received message: " + message);
    System.out.println("Partition: " + partition);
}

In the listen() method, we directly extract the RECEIVED_PARTITION header using the @Header annotation. This annotation allows us to specify the header we want to extract and its corresponding type. Injecting the value of the header directly into the method parameter (in this case, partition) enables direct access within the method body.

Below is the output:

Received message: Hello Baeldung!
Partition: 0

5. Conclusion

In this article, we’ve explored the significance of Kafka headers in message processing within Apache Kafka. We’ve explored the default headers that both producers and consumers automatically include. Additionally, we’ve learned how to extract and work with these headers.

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

       

1. Introduction

Spring Dat;u JPA provides a query derivation feature, using which we can derive queries automatically by just following the method name conventions.

In this article, we’ll use the query derivation feature to find entities by one or more columns.

2. Example Setup

For example purposes, we’ll use an Account entity which contains properties related to the user account:

@Entity
@Table(name = "ACCOUNTS")
public class Account {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "accounts_seq")
    @SequenceGenerator(name = "accounts_seq", sequenceName = "accounts_seq", allocationSize = 1)
    @Column(name = "user_id")
    private int userId;
    private String username;
    private String password;
    private String email;
    private Timestamp createdOn;
    private Timestamp lastLogin;
    @OneToOne
    @JoinColumn(name = "permissions_id")
    private Permission permission;
    
    // getters and setters
}

For demo purposes, we’ll also add some sample data to the Accounts table:

3. Query Derivation

Query derivation allows the developer to define method names in the repository interface that follow a naming convention, and the framework generates an appropriate query based on that method name.

For example, if we want to search the accounts table by email address, then our method in AccountRepository would look like below:

public interface AccountRepository extends JpaRepository<Account, Integer> {
    Account findByEmail(String email);
}

If we execute findByEmail() on AccountRepository, Spring Data generates the SQL below and executes it against the accounts table:

select a1_0.user_id,a1_0.created_on,a1_0.email,a1_0.last_login,a1_0.password,a1_0.permissions_id,a1_0.username
from accounts a1_0 
where a1_0.email=?

Our test verifies the working of findByEmail() :

@Test
void givenAccountInDb_whenPerformFindByEmail_thenReturnsAccount() {
    String email = "test@test.com";
    Account account = accountRepository.findByEmail(email);
    assertThat(account.getEmail()).isEqualTo(email);
}

4. findBy() With Multiple Columns

We can extend the query derivation feature to add a combination of conditions to get an appropriate result.

Let’s use the AccountRepository interface and write another method for finding Accounts with usernames and emails:

public interface AccountRepository extends JpaRepository<Account, Integer> {
    Account findByUsernameAndEmail(String username, String email);
}

Here’s the generated SQL for the defined method:

select a1_0.user_id,a1_0.created_on,a1_0.email,a1_0.last_login,a1_0.password,a1_0.permissions_id,a1_0.username
from accounts a1_0
where a1_0.username=? and a1_0.email=?

Our test verifies the working of findByUsernameAndEmail():

@Test
void givenAccountInDb_whenPerformFindByUsernameAndEmail_thenReturnsAccount(){
    String email = "test@test.com";
    String username = "user_admin";
    Account account = accountRepository.findByUsernameAndEmail(username, email);
    assertThat(account.getUsername()).isEqualTo(username);
    assertThat(account.getEmail()).isEqualTo(email);
}

We can also use the OR operator to combine two conditions. For example, we can search by either username or email:

public interface AccountRepository extends JpaRepository<Account, Integer> {
    Account findByUsernameOrEmail(String username, String email);
}

Let’s see the generated SQL:

select a1_0.user_id,a1_0.created_on,a1_0.email,a1_0.last_login,a1_0.password,a1_0.permissions_id,a1_0.username
from accounts a1_0
where a1_0.username=? or a1_0.email=?

Now, let’s verify the working of findByUsernameOrEmail():

@Test
void givenAccountInDb_whenPerformFindByUsernameOrEmail_thenReturnsAccount(){
    String email = "test@test.com";
    String username = "user_editor";
    Account account = accountRepository.findByUsernameOrEmail(username, email);
    assertThat(account.getUsername()).isNotEqualTo(username);
    assertThat(account.getEmail()).isEqualTo(email);
}

We can use the collection of input in findBy() method. For example, to find all accounts that exist in the list of emails or list of usernames, we can write a method in AccountRepository:

public interface AccountRepository extends JpaRepository<Account, Integer> {
    List<Account> findByUsernameInOrEmailIn(List<String> usernames, List<String> emails);
}

Let’s check out the generated SQL:

select a1_0.user_id,a1_0.created_on,a1_0.email,a1_0.last_login,a1_0.password,a1_0.permissions_id,a1_0.username 
from accounts a1_0 
where a1_0.username in (?,?) or a1_0.email in (?,?,?)

Our test confirms the working of findByUsernameInOrEmailIn():

@Test
void givenAccountInDb_whenPerformFindByUsernameInOrEmailIn_thenReturnsAccounts(){
    List<String> emails = List.of("test@test.com", "abc@abc.com", "pqr@pqr.com");
    List<String> usernames = List.of("user_editor", "user_admin");
    List<Account> byUsernameInOrEmailIn = accountRepository.findByUsernameInOrEmailIn(usernames, emails);
    assertThat(byUsernameInOrEmailIn.size()).isEqualTo(1);
    assertThat(byUsernameInOrEmailIn.get(0).getEmail()).isEqualTo("test@test.com");
}

5. Conclusion

In this tutorial, we discussed the query derivation feature of Spring Data and used it to find entities in a table. We also explored the usage of various input parameters for finding entities with conditions such as AND and OR.

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

       

1. Overview

Apache Camel is a Java framework that makes it easy to implement various Enterprise Integration Patterns (EIPs) for providing solutions to enterprise integration.

One of the common tasks in an integration pattern is to determine the message route at a runtime based on specific rules and conditions. Apache Camel simplifies this process by providing a method to implement Dynamic Router EIP.

In this tutorial, we’ll delve into details of how to implement dynamic routing in Apache Camel and walk through an example.

2. Understanding the Dynamic Router

Occasionally, there are cases where we want to send messages to different routes based on specific rules and conditions at runtime. Solutions like the Routing Slip EIP can help solve the problem, but it is less efficient because it use trial-and-error.

In Routing Slip EIP, a message contains the list of endpoints to route to in a defined order. This requires pre-configuring the endpoint list and uses a trial-and-error approach to send messages through each endpoint.

The Dynamic Router EIP provides better implementation to add a route at runtime, especially in a case where we have multiple recipients or none at all. It provides flexibility to route messages without pre-configured strict endpoints.

Additionally, it knows every destination and rules for routing a message to a specific destination. Also, it has a control channel that potential destinations communicate to by announcing their presence and rule of engagement on startup.

Furthermore, it stores the rules for all possible destinations in a rule base. Once a message arrives, it checks the rule base and fulfills the request of a recipient.

Here’s an image showing the internals of Dynamic Router EIP:

Moreover, a common use case is dynamic service discovery, where a client application can access a service by sending a message containing the name of the service.

The core goal of Dynamic Router EIP is to defer the routing decision to runtime rather than building static rules upfront.

3. Maven Dependencies

Let’s bootstrap a simple Apache Camel project by adding the camel-core and camel-test-junit5 to the pom.xml:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-core</artifactId>
    <version>4.3.0</version>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-test-junit5</artifactId>
    <version>4.3.0</version>
</dependency>

The Camel Core provides the Dynamic Router EIP along with other routing capabilities, and Camel Test JUnit5 helps make testing message routes easier with the CamelSupport interface.

Notably, we can also bootstrap the Camel project as a Spring Boot project.

4. Add Route at Runtime Using the Dynamic Router

The Dynamic Router EIP ensures that we specify rules for an integration system to aid right matching to a specific route at runtime. It checks for the incoming message’s body and matches it to a route.

4.1. Configuration

First, let’s create a class named DynamicRouteBean and add a method to define rules and conditions:

class DynamicRouterBean {
    public String route(String body, @ExchangeProperties Map<String, Object> properties) {
        int invoked = (int) properties.getOrDefault("invoked", 0) + 1;
        properties.put("invoked", invoked);
        if (invoked == 1) {
            switch (body.toLowerCase()) {
                case "mock":
                    return "mock:dynamicRouter";
                case "direct":
                    return "mock:directDynamicRouter";
                case "seda":
                    return "mock:sedaDynamicRouter";
                case "file":
                    return "mock:fileDynamicRouter";
                default:
                    break;
            }
        }
        return null;
    }
}

In the code above, we dynamically determine the appropriate route based on the incoming message body and current invocation count. The route() method checks if the message body matches any of the predefined keyword rules and returns the corresponding route.

Furthermore, we use the @ExchangeProperties annotation on a Map object. This map serves as a container to store and retrieve the current state of the exchange and update the invocation count.

Also, the invoked variable represents the number of times the route() method has been invoked. If the message matches a predefined condition and it’s the first invocation, the corresponding route is returned. The invoked == 1 check helps to execute the dynamic routing logic on the first invocation. This simplifies the code in this specific case and prevents unnecessary re-execution.

Also, to prevent endless execution of the Dynamic Router, the route() method returns null after routing to the appropriate endpoint. This ensures dynamic routing concludes after a route is identified based on the message.

Simply put, the route() method is called for every exchange until a null is returned.

Finally, let’s configure the Dynamic Router EIP in our Camel route builder:

class DynamicRouterRoute extends RouteBuilder {
    @Override
    void configure() {
        from("direct:dynamicRouter")
          .dynamicRouter(method(DynamicRouterBean.class, "route"));
    }
}

In the code above, we create the DynamicRouterRoute class that extends RouteBuilder. Next, we override the configure method and add the dynamic route bean by invoking the dyamicRouter() method to wire the Dynamic Router call to our custom route().

Notably, we can use @DynamicRouter annotation on the method that defines our rules:

class DynamicRouterBean {
    @DynamicRouter
    String route(String body, @ExchangeProperties Map<String, Object> properties) {
        // ...
    }
}

The annotation eliminates the need to explicitly configure dynamicRouter() method in the Camel route:

// ...
@Override
void configure() {
    from("direct:dynamicRouter").bean(DynamicRouterBean.class, "route");
}  
// ...

In the code above, we specify the class that contains the routing logic using the bean() method. The dynamicRouter() method is no longer needed because the route() method is annotated with @DynamicRouter.

4.2. Unit Test

Let’s write a unit test to assert if some of the conditions are true. First, let’s ensure our test class extends CamelTestSupport:

class DynamicRouterRouteUnitTest extends CamelTestSupport {
    @Override
    protected RoutesBuilder createRouteBuilder() {
        return new DynamicRouterRoute();
    } 
}

Here, provide an instance of DynamicRouterRoute to be used as a route builder for testing.

Next, let’s see an incoming message body named mock:

@Test
void whenMockEndpointExpectedMessageCountOneAndMockAsMessageBody_thenMessageSentToDynamicRouter() throws InterruptedException {
    MockEndpoint mockDynamicEndpoint = getMockEndpoint("mock:dynamicRouter");
    mockDynamicEndpoint.expectedMessageCount(1);
    template.send("direct:dynamicRouter", exchange -> exchange.getIn().setBody("mock"));
    MockEndpoint.assertIsSatisfied(context);
}

Here, we mock the dynamic endpoint and set the expected message route as its value. Next, we set the expected message count to one. Finally, we set an incoming message route with an expected body message and assert the MockEndpoint route is satisfied.

Also, let’s mock the “mock:directDynamicRouter” message route:

@Test
void whenMockEndpointExpectedMessageCountOneAndDirectAsMessageBody_thenMessageSentToDynamicRouter() throws InterruptedException {
    MockEndpoint mockDynamicEndpoint = context.getEndpoint("mock:directDynamicRouter", MockEndpoint.class);
    mockDynamicEndpoint.expectedMessageCount(1);
    template.send("direct:dynamicRouter", exchange -> exchange.getIn().setBody("direct"));
    MockEndpoint.assertIsSatisfied(context);
}

This test validates that when “direct” is sent as the message body, it gets routed dynamically to the “mock:directDynamicRouter” endpoint. Also, we set the expected message count to one, indicating the number of message exchanges that the endpoint should receive.

5. Conclusion

In this article, we learned how to add routes at runtime in Apache Camel using the Dynamic Router EIP. Unlike Routing Slip which uses a try-and-error approach to send a message to a route, Dynamic Router EIP provides a solid implementation to route to an endpoint based on specific rules and conditions.

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

       

1. Introduction

Apache Kafka is a powerful distributed streaming platform that is widely used for building real-time data pipelines and streaming applications. However, Kafka may encounter various exceptions and errors during operation. One such exception that is commonly faced is the InstanceAlreadyExistsException.

In this tutorial, we’ll explore the significance of this exception within Kafka. We’ll also delve into its root causes and effective Java application handling techniques.

2. What Is InstanceAlreadyExistsException?

The InstanceAlreadyExistsException is a subclass of the java.lang.RuntimeException class. In the context of Kafka, this exception typically arises when attempting to create a Kafka producer or consumer with a client ID identical to an existing producer or consumer.

Each Kafka client instance possesses a unique client ID, essential for metadata tracking and client connection management within the Kafka cluster. If an attempt is made to create a new client instance with a client ID already used by an existing client, Kafka throws InstanceAlreadyExistsException.

3. Internal Mechanisms

While we mention Kafka throwing this exception, it’s noteworthy that Kafka typically manages this exception gracefully within its internal mechanisms. By handling the exception internally, Kafka can isolate and contain the issue within its own subsystems. This prevents the exception from impacting the main application thread and potentially causing broader system instability or downtime.

In Kafka’s internal implementation, the registerAppInfo() method is usually invoked during the initialization of a Kafka client (producer or consumer). Suppose there’s an existing client with the same client.id, this method catches InstanceAlreadyExistsException. Since the exception is handled internally, it won’t be thrown up to the main application thread, where one might expect to catch exceptions.

4. Causes of InstanceAlreadyExistsException

In this section, we’ll examine various scenarios leading to the InstanceAlreadyExistsException, along with code examples.

4.1. Duplicate Client IDs in Consumer Groups

Kafka mandates distinct client IDs for consumers within the same consumer group. When multiple consumers within a group share identical client IDs, Kafka’s message delivery semantics may become unpredictable. This can interfere with Kafka’s ability to manage offsets and maintain message ordering, potentially resulting in message duplication or loss. Thus, the occurrence of this exception is triggered when multiple consumers share the same client ID.

Let’s attempt to create multiple KafkaConsumer instances using the same client.id. To initialize the Kafka consumer, we need to define the Kafka properties, including essential configurations such as bootstrap.servers, key.deserializer, value.deserializer, etc.

Below is a code snippet illustrating the definition of Kafka consumer properties:

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("client.id", "my-consumer");
props.put("group.id", "test-group");
props.put("key.deserializer", StringDeserializer.class);
props.put("value.deserializer", StringDeserializer.class);

Next, we create three KafkaConsumer instances using the same client.id in a multi-threaded environment:

for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)
    }).start();
}

In this example, multiple threads are created, each attempting to create a Kafka consumer with the same client ID, my-consumer, concurrently. Due to the concurrent execution of these threads, multiple instances with the same client ID being created simultaneously. This leads to the InstanceAlreadyExistsException as expected.

4.2. Failure to Properly Close Existing Kafka Producer Instances

Similar to Kafka consumers, if we attempt to create two Kafka producer instances with the same client.id property or reinstantiate a Kafka producer without properly closing the existing instance, Kafka rejects the second initialization attempt. This action throws an InstanceAlreadyExistsException because Kafka doesn’t permit multiple producers with the same client ID to coexist concurrently.

Here’s a code example to define the Kafka producer properties:

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("client.id", "my-producer");
props.put("key.serializer", StringSerializer.class);
props.put("value.serializer", StringSerializer.class);

Then, we create a KafkaProducer instance with the specified properties. Next, we attempt to reinitialize the Kafka producer with the same client ID without closing the existing instance properly:

KafkaProducer<String, String> producer1 = new KafkaProducer<>(props);
// Attempt to reinitialize the producer without closing the existing one
producer1 = new KafkaProducer<>(props);

In this scenario, an InstanceAlreadyExistsException is thrown because the Kafka producer instance with the identical client ID has already been created. If this producer instance hasn’t been properly closed and we attempt to reinitialize another Kafka producer with the same client ID, the exception occurs.

4.3. JMX Registration Conflicts

JMX (Java Management Extensions) enables applications to expose management and monitoring interfaces, enabling monitoring tools to interact with and manage the application runtime. In Kafka, various components, such as brokers, producers, and consumers, expose JMX metrics for monitoring purposes.

When utilizing JMX with Kafka, conflicts can arise if multiple MBeans (Managed Beans) attempt to register under the same name within the JMX domain. This can lead to registration failures and the InstanceAlreadyExistsException. For example, if different parts of the application are configured to expose JMX metrics using the same MBean name.

To illustrate, let’s consider the following example demonstrating how JMX registration conflicts can occur. First, we create a class named MyMBean and implement the DynamicMBean interface. This class serves as a representation of the management interface that we want to expose for monitoring and management purposes via JMX:

public static class MyMBean implements DynamicMBean {
    // Implement required methods for MBean interface
}

Next, we create two instances of the MBeanServer using the ManagementFactory.getPlatformMBeanServer() method. These instances allow us to manage and monitor MBeans within the Java Virtual Machine (JVM).

Afterward, we define the same ObjectName for both MBeans, using kafka.server:type=KafkaMetrics as a unique identifier within the JMX domain:

MBeanServer mBeanServer1 = ManagementFactory.getPlatformMBeanServer();
MBeanServer mBeanServer2 = ManagementFactory.getPlatformMBeanServer();
ObjectName objectName = new ObjectName("kafka.server:type=KafkaMetrics");

Subsequently, we instantiated two instances of MyMBean and proceeded to register them utilizing the previously defined ObjectName:

MyMBean mBean1 = new MyMBean();
mBeanServer1.registerMBean(mBean1, objectName);
// Attempt to register the second MBean with the same ObjectName
MyMBean mBean2 = new MyMBean();
mBeanServer2.registerMBean(mBean2, objectName);

In this example, we attempt to register two MBeans with the same ObjectName on two different instances of the MBeanServer. This leads to an InstanceAlreadyExistsException because each MBean must have a unique ObjectName when registered with an MBeanServer.

5. Handling InstanceAlreadyExistsException

The InstanceAlreadyExistsException in Kafka can cause significant issues if not handled properly. When this exception occurs, critical operations like producer initialization or consumer group joining may fail, potentially resulting in data loss or inconsistency.

Moreover, duplicate registrations of MBeans or Kafka clients can waste resources, causing inefficiencies. Hence, it’s crucial to handle this exception when working with Kafka.

5.1. Ensure Unique Client IDs

A key factor leading to the InstanceAlreadyExistsException is the attempt to instantiate multiple Kafka producer or consumer instances with identical client IDs. Hence, it’s crucial to guarantee that each Kafka client within a consumer group or producer possesses a distinct client ID to avert conflicts.

To achieve uniqueness in client IDs, we can employ the UUID.randomUUID() method. This function generates universally unique identifiers (UUIDs) based on random numbers, thereby minimizing the likelihood of collisions. Consequently, UUIDs serve as suitable options for generating unique client IDs in Kafka applications.

Here’s an illustration of how to generate a unique client ID:

String clientId = "my-consumer-" + UUID.randomUUID();
properties.setProperty("client.id", clientId);

5.2. Properly Handling KafkaProducer Closure

When re-instantiating a KafkaProducer, it’s crucial to close the existing instance properly to release resources. Here’s how we can achieve this:

KafkaProducer<String, String> producer1 = new KafkaProducer<>(props);
producer1.close();
producer1 = new KafkaProducer<>(props);

5.3. Ensure Unique MBean Names

To avoid conflicts and potential InstanceAlreadyExistsException related to JMX registrations, it’s important to ensure unique MBean names, especially in environments where multiple Kafka components expose JMX metrics. We should explicitly define unique ObjectNames for each MBean when registering them with the MBeanServer.

Here’s an example:

ObjectName objectName1 = new ObjectName("kafka.server:type=KafkaMetrics,id=metric1");
ObjectName objectName2 = new ObjectName("kafka.server:type=KafkaMetrics,id=metric2");
mBeanServer1.registerMBean(mBean1, objectName1);
mBeanServer2.registerMBean(mBean2, objectName2);

6. Conclusion

In this article, we explored the significance of the InstanceAlreadyExistsException within Apache Kafka. This exception typically occurs when trying to create a Kafka producer or consumer with the same client ID as an existing one. To mitigate these issues, we discussed several handling techniques. By leveraging mechanisms such as UUID.randomUUID(), we can ensure that each producer or consumer instance possesses a distinct identifier.

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

       

1. Spring and Java

>> Pattern match Optional in Java 21 [joda.org]

Exploring Optional Pattern Matching in Java 21: a deep dive into the latest features.

>> When should a compiler expand garbage collection barriers? [robcasloz.io]

Analyzing Compiler Strategies: determining the optimal expansion of garbage collection barriers. Quite technical but worth reading over the weekend.

>> Creating a REST API from an existing Database using Graal Cloud Native [oracle.com]

GraalVM Magic: crafting REST APIs from Databases in a Cloud-Native World

Also worth reading:

• >> State of jextract [cr.openjdk.org]
• >> An Efficient Way to Check for Existence of Multiple Values in SQL [jooq.org]
• >> Minimize Costs by Utilizing Cloud Storage with Spring-Data-Eclipse-Store [foojay.io]
• >> Top Most Detected Issues in Java Projects [foojay.io]
• >> Java at the heart of delivering German Health Care Insurance excellence [oracle.com]
• >> How to keep engineers out of meeting hell [morethancoding.com]

Webinars and presentations:

• >> Foreign Function & Memory API – A (quick) peek under the hood [inside.java]
• >> Does Java 22 Kill Build Tools? – Inside Java Newscast #63 [inside.java]
• >> A Bootiful Podcast: Oracle Java Developer Advocate Nicolai Parlog on the latest and greatest in Java [spring.io]
• >> Video: Spring Boot Testcontainers Support for Local Development [foojay.io]
• >> Virtual Threads – Next Steps [inside.java]
• >> Java Language Update – Early 2024 Edition [inside.java]
• >> Build Flexible Jakarta EE Applications With Apache CouchDB NoSQL Database [foojay.io]

Time to upgrade:

• >> Spring Framework 6.1.4, 6.0.17 and 5.3.32 Available Now [spring.io]
• >> Spring Data 2023.1.3 and 2023.0.9 available [spring.io]
• >> First milestone of Spring Data 2024.0.0 available [spring.io]
• >> Spring for Apache Pulsar 1.0.3 available now [spring.io]
• >> Oracle Graal Cloud Native 4.2.1 Brings Java 21 Support, New Cloud Integrations, and More [infoq.com]

2. Technical & Musings

>> PostgreSQL Performance Tuning Settings [vladmihalcea.com]

A comprehensive guide to PostgreSQL Performance Tuning and key settings. Interesting if you’re using PostgreSQL.

Also worth reading:

• >>How to keep engineers out of meeting hell [morethancoding.com]
• >> Engineering Practices for LLM Application Development [martinfowler.com]
• >> DoorDash Uses CockroachDB to Create Config Management Platform for Microservices [infoq.com]
• >> State of Open (Source?!) and Free AI – a FOSDEM recap [foojay.io]
• >> Implementing Closing the Books pattern [event-driven.io]
• >> Secure your API with these 16 Practices with Apache APISIX [frankel.ch]

3. Pick of the Week

>> Move beyond GlassFish with Payara Server [payara.fish]

       

1. Overview

The Rod Cutting Problem is a classic optimization problem that involves finding the best way to cut a rod into pieces to maximize the total revenue.

In this tutorial, we’ll understand the Rod Cutting Problem and explore various approaches to solving it in Java.

2. Understanding the Problem

Imagine we’ve got a rod of length n. We’ve got the flexibility to cut this rod into various lengths and sell those cut segments. Furthermore, we possess a table of prices for different lengths of cut rods. Our goal is to maximize the total revenue.

For example, consider a rod of length n=4 with prices Pi = [1,5,8,9]. The Pi array denotes the price of a rod piece of length i. It means:

P1 = 1 shows the price of a rod piece of length 1 is 1 unit.

P2 = 5 shows the price of a rod piece of length 2 is 5 units.

Similarly, P3 = 8 shows the price of a rod piece of length 3 is 8 units, and

P4 = 9 shows the price of a rod piece of length 4 is 9 units.

We can make various cuts to the rod, and each cut will result in a certain revenue based on the prices of the rod pieces. Here are the possible cuts for a rod of length 4:

• Cut into 4 pieces of length 1m each [1,1,1,1], resulted in revenue = 1+1+1+1 = $4
• Cut into 2 pieces of length 2m each [2,2], resulted in revenue = 5+5 = $10
• Cut into 1 piece of length 4m, resulted in revenue = $9
• Cut into 3 pieces of length 1m and 2m [1,1,2], resulted in revenue = 1+1+5 = $7
• Cut into 3 pieces of length 1m and 2m [1,2,1], resulted in revenue = 1+5+1 = $7
• Cut into 3 pieces of length 1m and 2m [2,1,1], resulted in revenue= 5+1+1 = $7

Here, we can see that by cutting our rod into 2 pieces of length 2m each, we get a total price of $10. Every other combination gives a lower price, so we can see that this is the optimal answer.

3. Recursive Solution

The recursive solution involves decomposing the problem into subproblems and solving them recursively. The recurrence relation used to calculate the maximum revenue for a rod of length n is R_n = max_1<=i<=n(P_i+R_n-i).

In the above relation, R_n represents the maximum revenue for a rod of length n, and P_i is the price of a rod piece of length i. Let’s implement the recursive solution:

int usingRecursion(int[] prices, int n) {
    if (n <= 0) {
        return 0;
    }
    int maxRevenue = Integer.MIN_VALUE;
    for (int i = 1; i <= n; i++) {
        maxRevenue = Math.max(maxRevenue, prices[i - 1] + usingRecursion(prices, n - i));
    }
    return maxRevenue;
}

In our example, we check the base case to determine if the rod’s length is equal to or less than 0, resulting in a revenue of 0. We systematically explore all potential cuts using recursion to calculate the maximum revenue for each cut. The result is the highest revenue achieved among all the cuts.

Now, let’s test this approach:

<span class="pl-c1">@</span><span class="pl-c1"><span class="pl-token">Test</span></span><br />void givenARod_whenUsingRecursion_thenFindMaxRevenue() {
    int[] prices = {1, 5, 8, 9};
    int rodLength = 4;
    int maxRevenue = RodCuttingProblem.usingRecursion(prices, rodLength);
    assertEquals(10, maxRevenue);
}

The recursive approach works and is relatively easy to understand. However, its exponential time complexity O(2ⁿ) makes it impractical for larger instances, as recursive calls will rapidly increase. So, if we’ve got a 4m rod, this approach will take 2⁴ = 16 iterations.

The lack of memorization in this approach results in redundant computations, as identical subproblems are solved multiple times during the recursive exploration. This inefficiency becomes a significant concern for realistic scenarios with rods of considerable lengths.

4. Memoized Recursive Solution

We can improve our recursive solution by the use of memoization. In this approach, we’ll use a memoization table to store and reuse the results of previously solved subproblems:

int usingMemoizedRecursion(int[] prices, int n) {
    int[] memo = new int[n + 1];
    Arrays.fill(memo, -1);
    return memoizedHelper(prices, n, memo);
}
int memoizedHelper(int[] prices, int n, int[] memo) {
    if (n <= 0) {
        return 0;
    }
    if (memo[n] != -1) {
        return memo[n];
    }
    int maxRevenue = Integer.MIN_VALUE;
    for (int i = 1; i <= n; i++) {
        maxRevenue = Math.max(maxRevenue, prices[i - 1] + memoizedHelper(prices, n - i, memo));
    }
    memo[n] = maxRevenue;
    return maxRevenue;
}

The idea is to avoid redundant computations by checking whether a subproblem has already been solved before solving it again. Our memoization table takes the form of an array, where each index corresponds to the rod length, and the associated value holds the maximum revenue for that specific length.

Now, let’s test this approach:

<span class="pl-c1">@</span><span class="pl-c1"><span class="pl-token">Test</span></span><br />void givenARod_whenUsingMemoizedRecursion_thenFindMaxRevenue() {
    int[] prices = {1, 5, 8, 9};
    int rodLength = 4;
    int maxRevenue = RodCuttingProblem.usingMemoizedRecursion(prices, rodLength);
    assertEquals(10, maxRevenue);
}

By avoiding the redundant calculations through memoization, the time complexity is significantly reduced compared to the naive recursive solution. Now, the time complexity is determined by the number of unique subproblems solved, and for the Rod Cutting problem, it is often O(n²) due to the two nested loops.

This means for a rod of length 10m, we’ll have a time complexity of 100 here, compared to 1024 before, because we’re doing notably less work due to the trimming of nodes. However, this comes at a cost in space complexity. The previous algorithm didn’t store any state, whereas this one will need to store up to one value for each possible rod length, giving it a space complexity of O(n).

5. Dynamic Programming Solution

Another approach to solving this problem is via dynamic programming. Dynamic programming solves a problem by dividing it into smaller subproblems. This is very similar to the divide-and-conquer algorithm-solving technique. The major difference, however, is that dynamic programming solves a subproblem only once.

5.1. Iterative (Bottom-Up) Approach

In this approach, avoiding recursion and using an iterative process eliminates the function call overhead associated with the recursive solutions, contributing to enhanced performance:

int usingDynamicProgramming(int[] prices, int n) {
    int[] dp = new int[n + 1];
    for (int i = 1; i <= n; i++) {
        int maxRevenue = Integer.MIN_VALUE;
        for (int j = 1; j <= i; j++) {
            maxRevenue = Math.max(maxRevenue, prices[j - 1] + dp[i - j]);
        }
        dp[i] = maxRevenue;
    }
    return dp[n];
}

Let’s test this approach as well:

<span class="pl-c1">@</span><span class="pl-c1"><span class="pl-token">Test</span></span><br />void givenARod_whenUsingDynamicProgramming_thenFindMaxRevenue() {
    int[] prices = {1, 5, 8, 9};
    int rodLength = 4;
    int maxRevenue = RodCuttingProblem.usingDynamicProgramming(prices, rodLength);
    assertEquals(10, maxRevenue);
}

Our dynamic programming table, represented by the dp array, stores the optimal solutions for each subproblem, where the index i corresponds to the rod length, and dp[i] holds the maximum revenue. The final entry in the dp array, dp[n], contains the maximum revenue for the original problem of a rod with length n.

This approach is also memory-efficient as it doesn’t require an additional memoization table.

5.2. Unbounded Knapsack Solution

The unbounded knapsack approach is a dynamic programming technique used to solve optimization problems where an item can be chosen unlimited times. This means that the same cut length can be selected and included in the rod multiple times if it contributes to maximizing the revenue.

Let’s take a look at the implementation:

int usingUnboundedKnapsack(int[] prices, int n) {
    int[] dp = new int[n + 1];
    for (int i = 1; i <= n; i++) {
        for (int j = 0; j < prices.length; j++) {
            if (j + 1 <= i) {
                dp[i] = Math.max(dp[i], dp[i - (j + 1)] + prices[j]);
            }
        }
    }
    return dp[n];
}

Similar to the iterative (bottom-up) approach, this algorithm computes the maximum revenue for each rod length.

Let’s test this approach:

<span class="pl-c1">@</span><span class="pl-c1"><span class="pl-token">Test</span></span><br />void givenARod_whenUsingGreedy_thenFindMaxRevenue() {
    int[] prices = {1, 5, 8, 9};
    int rodLength = 4;
    int maxRevenue = RodCuttingProblem.usingUnboundedKnapsack(prices, rodLength);
    assertEquals(10, maxRevenue);
}

The drawback of this approach is the potential for increased space complexity. 

6. Conclusion

In this tutorial, we’ve understood the Rod Cutting Problem and discussed various ways to solve it.

The recursive approach offers simplicity but suffers from exponential time complexity. The memoization method addresses this by reusing solutions and introducing slight space complexity. The iterative approach further improves efficiency, eliminating recursion overhead.

The choice between these approaches depends on specific problem characteristics, involving trade-offs in time, space, and implementation complexity.

As always, the code used in the examples is available over on GitHub.

       

1. Introduction

Often, when working with several programming scenarios, there will be strings that contain numbers, and it might be necessary to find the greatest among these values.

In this tutorial, we’ll delve into different ways and Java code illustrations for properly identifying and extracting the greatest numeric value from a given string.

2. String Parsing with Comparison

The simplest method includes reading the strings and identifying the numeric substrings. We can detect the largest number through a comparison of the prefixes. Let’s take an example:

String inputString = "The numbers are 10, 20, and 5";
int expectedLargestNumber = 20;
@Test
void givenInputString_whenUsingBasicApproach_thenFindingLargestNumber() {
    String[] numbers = inputString.split("[^0-9]+");
    int largestNumber = Integer.MIN_VALUE;
    for (String number : numbers) {
        if (!number.isEmpty()) {
            int currentNumber = Integer.parseInt(number);
            if (currentNumber > largestNumber) {
                largestNumber = currentNumber;
            }
        }
    }
    assertEquals(expectedLargestNumber, largestNumber);
}

Here, we first use the split() method to split the input string named inputString into an array of sub-strings. Such division takes place through a regular expression, [^0-9]+, that intercepts only digits in the string.

Subsequently, a regular loop illustrates the string splitting. The loop restricts the array to having the resulting substrings and, on purpose, no empty strings. The implementation of each non-empty substring contains a prominent conversion with the Integer.parseInt() method.

Afterwards, a comparison between the current numeric value and the largestNumber found so far takes place, and an update happens in case a larger value is encountered. Finally, we use the assertEquals() method to ensure that the largestNumber is equal to the expectedLargestNumber.

3. Efficient Numeric Extraction with Regular Expressions

Regular expressions are the ones that allow us to extract the numeric values from a string concisely and effectively. Taking advantage of the Pattern and Matcher classes, we thus make the process more streamlined. Here’s a simple example:

@Test
void givenInputString_whenUsingRegularExpression_thenFindingLargestNumber() {
    Pattern pattern = Pattern.compile("\\d+");
    Matcher matcher = pattern.matcher(inputString);
    int largestNumber = Integer.MIN_VALUE;
    while (matcher.find()) {
        int currentNumber = Integer.parseInt(matcher.group());
        if (currentNumber > largestNumber) {
            largestNumber = currentNumber;
        }
    }
    assertEquals(expectedLargestNumber, largestNumber);
}

Here, we start by compiling a regular expression (\d+) using the Pattern.compile() method. This expression is meticulously designed to focus on matching one or more digits within the input string.

Then, we initialize the Matcher object, denoted as a matcher, by applying the compiled pattern to the inputString.

Afterward, we enter a subsequent while loop. The numeric value is extracted within each iteration using the Integer.parseInt(matcher.group()) method. A crucial comparison unfolds, assessing this current numeric value against the existing largestNumber. Should a larger value be discovered, the largestNumber is promptly updated to reflect this identification.

4. Stream and Lambda Expressions

Java 8 proposes the Stream API and lambda expression; therefore, the code is more compact and easier-to-read.

Let’s take a simple implementation:

@Test
void givenInputString_whenUsingStreamAndLambdaExpression_thenFindingLargestNumber() {
    int largestNumber = Arrays.stream(inputString.split("[^0-9]+"))
      .filter(s -> !s.isEmpty())
      .mapToInt(Integer::parseInt)
      .max()
      .orElse(Integer.MIN_VALUE);
    assertEquals(expectedLargestNumber, largestNumber);
}

In this test method, we begin by filtering the string to extract its numeric components exclusively, which is achieved through the utilization of the split() method. Additionally, we incorporate measures to address the potential occurrence of an empty stream, implementing the isEmpty() method.

Following the initial filtering, we leverage the mapToInt() method to systematically convert each non-empty substring into an integer, facilitated by the Integer::parseInt reference. Subsequently, the max() operation efficiently identifies the largest integer value present within the processed stream.

We employ the orElse() method to wrap up the streamlined approach, strategically setting the default value to Integer.MIN_VALUE.

5. Conclusion

In conclusion, this tutorial is a thorough examination of techniques that make it easier to work with strings containing numbers in Java.

As always, the complete code samples for this article can be found over on GitHub.

       

1. Introduction

Java’s CompletableFuture framework provides powerful asynchronous programming capabilities, facilitating the execution of tasks concurrently.

In this tutorial, we’ll delve into two essential methods offered by CompletableFuture –  runAsync() and supplyAsync(). We’ll explore their differences, use cases, and when to choose one over the other.

2. Understanding CompletableFuture, runAsync() and supplyAsync()

CompletableFuture is a powerful framework in Java that enables asynchronous programming, facilitating the execution of tasks concurrently without blocking the main thread. runAsync() and supplyAsync() are methods provided by the CompletableFuture class.

Before we dive into a comparison, let’s understand the individual functionalities of runAsync() and supplyAsync(). Both methods initiate asynchronous tasks, allowing us to execute code concurrently without blocking the main thread.

runAsync() is a method used to execute a task asynchronously that doesn’t produce a result. It’s suitable for fire-and-forget tasks where we want to execute code asynchronously without waiting for a result. For example, logging, sending notifications, or triggering background tasks.

On the other hand, supplyAsync() is a method used to asynchronously execute a task that produces a result. It’s ideal for tasks that require a result for further processing. For example, fetching data from a database, making an API call, or performing a computation asynchronously.

3. Input and Return

The main difference between runAsync() and supplyAsync() lies in the input they accept and the type of return value they produce.

3.1. runAsync()

The runAsync() method is employed when the asynchronous task to be executed doesn’t produce any result. It accepts a Runnable functional interface and initiates the task asynchronously. It returns a CompletableFuture<Void> and is useful for scenarios where the focus is on the completion of a task rather than obtaining a specific result.

Here’s a snippet showcasing its usage:

CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
    // Perform non-result producing task
    System.out.println("Task executed asynchronously");
});

In this example, the runAsync() method is used to execute a non-result producing task asynchronously. The provided lambda expression encapsulates the task to be executed. Upon completion, it prints:

Task completed successfully

3.2. supplyAsync()

On the other hand, supplyAsync() is employed when the asynchronous task yields a result. It accepts a Supplier functional interface and initiates the task asynchronously. Subsequently, it returns a CompletableFuture<T>, where T is the type of the result produced by the task.

Let’s illustrate this with an example:

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    // Perform result-producing task
    return "Result of the asynchronous computation";
});
// Get the result later
String result = future.get();
System.out.println("Result: " + result);

In this example, supplyAsync() is used to execute a result-producing task asynchronously. The lambda expression within supplyAsync() represents the task that computes the result asynchronously. Upon completion, it prints the obtained result:

Result: Result of the asynchronous computation

4. Exception Handling

In this section, we’ll discuss how both methods handle exceptions.

4.1. runAsync()

When using runAsync(), exception handling is straightforward. The method doesn’t provide an explicit mechanism for handling exceptions within the asynchronous task. As a result, any exceptions thrown during the execution of the task are propagated to the calling thread when invoking the get() method on the CompletableFuture. This means that we must handle exceptions manually after calling get().

Here’s a snippet demonstrating exception handling with runAsync():

CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
    throw new RuntimeException("Exception occurred in asynchronous task");
});
try {
    future.get(); // Exception will be thrown here
} catch (ExecutionException ex) {
    Throwable cause = ex.getCause();
    System.out.println("Exception caught: " + cause.getMessage());
}

The exception message is then printed:

Exception caught: Exception occurred in asynchronous task

4.2. supplyAsync()

In contrast, supplyAsync() provides a more convenient way to handle exceptions. It offers an exception-handling mechanism via the exceptionally() method. This method allows us to specify a function that will be invoked if the original asynchronous task completes exceptionally. We can use this function to handle the exception and return a default value or perform any necessary cleanup operations.

Let’s look at an example that demonstrates how exception handling works with supplyAsync():

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    throw new RuntimeException("Exception occurred in asynchronous task");
}).exceptionally(ex -> {
    // Exception handling logic
    return "Default value";
});
String result = future.join(); // Get the result or default value
System.out.println("Result: " + result);

In this example, if an exception occurs during the execution of the asynchronous task, the exceptionally() method will be invoked. This allows us to handle the exception gracefully and provide a fallback value if needed.

Instead of raising an exception, it prints:

Task completed with result: Default value

5. Execution Behavior

In this section, we’ll explore the execution behavior of CompletableFuture‘s runAsync() and supplyAsync() methods

5.1. runAsync()

When utilizing runAsync(), the task is launched instantly in a common thread pool. Its behavior mirrors that of invoking a new Thread(runnable).start(). This means that the task begins execution immediately upon invocation, without any delay or scheduling considerations.

5.2. supplyAsync()

On the other hand, supplyAsync() schedules the task in a common thread pool, potentially delaying its execution if other tasks are queued. This scheduling approach can be advantageous for resource management, as it helps prevent sudden bursts of thread creation. By queuing tasks and scheduling their execution based on the availability of threads, supplyAsync() ensures efficient resource utilization.

6. Chaining Operations

In this section, we’ll explore how CompletableFuture‘s runAsync() and supplyAsync() methods support chaining operations, highlighting their differences.

6.1. runAsync()

runAsync() method cannot be directly chained with methods like thenApply() or thenAccept() as it doesn’t produce a result. However, we can use thenRun() to execute another task after the runAsync() task completes. This method allows us to chain additional tasks for sequential execution without relying on the result of the initial task.

Below is an example showcasing the chaining operation using runAsync() and thenRun():

CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
    System.out.println("Task executed asynchronously");
});
future.thenRun(() -> {
    // Execute another task after the completion of runAsync()
    System.out.println("Another task executed after runAsync() completes");
});

In this example, we first execute a task asynchronously using runAsync(). Then, we use thenRun() to specify another task to be executed after the completion of the initial task. This allows us to chain multiple tasks sequentially, resulting in the following output:

Task executed asynchronously
Another task executed after runAsync() completes

6.2. supplyAsync()

In contrast, supplyAsync() allows chaining operations due to its return value. Since supplyAsync() produces a result, we can use methods like thenApply() to transform the result, thenAccept() to consume the result, or thenCompose() to chain further asynchronous operations. This flexibility enables us to build complex asynchronous workflows by chaining multiple tasks together.

Here’s an example illustrating the chaining operation with supplyAsync() and thenApply():

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    return "Result of the asynchronous computation";
});
future.thenApply(result -> {
    // Transform the result
    return result.toUpperCase();
}).thenAccept(transformedResult -> {
    // Consume the transformed result
    System.out.println("Transformed Result: " + transformedResult);
});

In this example, we first execute a task asynchronously using supplyAsync(), which produces a result. Then, we use thenApply() to transform the result and thenAccept() to consume the transformed result. This demonstrates the chaining of multiple operations with supplyAsync(), allowing for more complex asynchronous workflows.

Here’s an example of the output:

Transformed Result: RESULT OF THE ASYNCHRONOUS COMPUTATION

7. Performance

While both runAsync() and supplyAsync() execute tasks asynchronously, their performance characteristics can vary based on the nature of the tasks and the underlying execution environment.

7.1. runAsync()

Since runAsync() doesn’t produce any result, it may have a slightly better performance compared to supplyAsync(). This is because it avoids the overhead of creating a Supplier object. The absence of result handling logic can lead to faster task execution in certain scenarios.

7.2. supplyAsync()

Various factors influence the performance of supplyAsync(), including the complexity of the task, the availability of resources, and the efficiency of the underlying execution environment.

In scenarios where tasks involve complex computations or resource-intensive operations, the performance impact of using supplyAsync() may be more pronounced. However, the ability to handle results and dependencies between tasks can outweigh any potential performance overhead.

8. Use Cases

In this section, we’ll explore specific use cases for both methods.

8.1. runAsync()

The runAsync() method is particularly useful when the focus is on the completion of a task rather than obtaining a specific result. runAsync() is commonly employed in scenarios where background tasks or operations that don’t require returning a value are performed. For example, running periodic cleanup routines, logging events, or triggering notifications can all be achieved efficiently with runAsync().

8.2. supplyAsync()

In contrast to runAsync(), the supplyAsync() method is specifically useful when the completion of the task involves producing a value that may be utilized later in the application flow. One typical use case for supplyAsync() is fetching data from external sources, such as databases, APIs, or remote servers.

Additionally, supplyAsync() is suitable for executing computational tasks that generate a value as a result, such as performing complex calculations or processing input data.

9. Summary

Here’s a summary table comparing the key differences between runAsync() and supplyAsync():

10. Conclusion

In this article, we explored the runAsync() and supplyAsync() methods. We discussed their functionalities, differences, exception-handling mechanisms, execution behavior, chaining operations, performance considerations, and specific use cases.

While supplyAsync() is preferable when a result is needed, runAsync() is suitable for scenarios where the focus is solely on task completion without requiring a specific result.

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

       

1. Introduction

In the complex world of distributed systems, ensuring efficient data management is crucial. Distributed reliable key-value stores play a pivotal role in maintaining data consistency and scalability across distributed environments.

In this comprehensive tutorial, we’ll delve into etcd, an open-source distributed key-value store. We’ll explore its fundamental concepts, features, and use cases, and provide a hands-on quickstart guide. Finally, we’ll compare etcd with a couple of other distributed key-value stores to understand its strengths and unique offerings.

2. What Are Distributed Key-Value Stores?

Distributed key-value stores are a type of NoSQL database that stores data as key-value pairs that span multiple physical or virtual machines.

This distribution essentially enhances scalability, fault tolerance, and performance. Moreover, each piece of data (value) is associated with a unique identifier (key). This model is highly efficient for certain use cases, such as caching, configuration management, and fast data retrieval.

Apache Zookeeper, Consul, and Redis are some of the examples that provide a reliable key-value store.

Distributed key-value stores serve as the backbone of many distributed systems, providing a simple yet powerful mechanism for storing and retrieving data.

Below are some important key aspects of the distributed key-value stores:

• Simplicity: Basic data structure comprising key-value pairs, making it easy to understand and use for specific types of applications.
• Scalability: These systems can efficiently handle growing amounts of data and increased load by distributing the workload across multiple nodes.
• Reliability: They ensure data consistency, fault tolerance, and scalability.
• Performance: The key-value mechanism provides fast and efficient access to data. Moreover, by distributing it across multiple nodes, it reduces the load on individual machines.
• Distribution: Since the data is spread across multiple nodes, we get enhanced performance.

Distributed key-value stores find applications in various scenarios, such as configuration management, caching, session storage, service discovery, leader election, etc.

3. What Is etcd?

etcd is a distributed, reliable key-value store for the most critical data of a distributed system. It’s a simple, secure, fast, and reliable key-value store designed for configuration management, service discovery, and coordination of distributed systems.

Developed by the CoreOS team and now a CNCF (Cloud Native Computing Foundation) project, etcd provides a reliable and distributed data store that enables the coordination of configurations and the discovery of services in dynamic and scalable environments.

etcd is developed in Go and internally uses the Raft consensus algorithm to manage a highly-available replicated log.

Many companies worldwide such as Baidu, Huawei, Salesforce, Ticketmaster, etc. use etcd in production. It’s frequently integrated with applications such as Kubernetes, Locksmith, Vulcand, Doorman, and many others.

etcd’s rich feature set makes it a versatile and reliable choice for distributed systems, providing the essential building blocks for configuration management, service discovery, and coordination in cloud-native environments. Its commitment to distributed consistency, high availability, and strong data integrity positions it as a foundational component in the landscape of modern, scalable, and resilient applications.

4. Features of etcd

etcd’s rich feature set makes it a versatile and reliable choice for distributed systems, providing the essential building blocks for configuration management, service discovery, and coordination in cloud-native environments. In certain situations, it may achieve 10,000 writes/sec.

Let’s understand some of its key features:

• HTTP/gRPC API: etcd provides both HTTP and gRPC APIs, making it accessible and interoperable with various programming languages and easily integrated into different types of applications and frameworks.
• Distributed Consistency: It maintains strong consistency in distributed setups, ensuring that all nodes in the cluster have a consistent view of the data.
• High Availability: etcd is designed to be highly available, with automatic leader election and failover mechanisms. Thus, an etcd cluster remains operational even in the face of node failures, contributing to system resilience.
• Watch Support: etcd supports strongly consistent watches, allowing applications to monitor changes to specific key-value stores in real-time.
• Atomic Transactions: It supports atomic transactions, allowing multiple key-value operations that we can group together and execute as a single atomic unit, thus maintaining data consistency.
• Lease Management: etcd introduces the concept of leases, allowing keys to have associated time-to-live (TTL) values thus deleting them automatically after the specified period.
• Role-Based Access Control (RBAC): It supports RBAC, allowing administrators to define roles and permissions for users and applications interacting with the cluster.
• Snapshot and Backup: It provides mechanisms for creating snapshots of the cluster’s state and supports backup and restoration processes. Thus, it ensures disaster recovery and data durability.
• Pluggable Storage Backend: etcd offers a pluggable storage backend, enabling users to choose the underlying storage engine that best fits their requirements (e.g., etcd’s default storage engine, LevelDB, or RocksDB). Thus, it provides flexibility and allows optimization based on specific use cases and performance considerations.
• Integration with Kubernetes: etcd is a critical component in Kubernetes, serving as the primary datastore for configuration and state information. This makes etcd a core part of container orchestration, ensuring that the distributed systems can manage configurations and scale effectively.
• etcdctl: It’s a command-line client tool designed for interacting with and managing an etcd cluster.

5. Installation

Let’s understand how to configure and set up etcd to get it running. etcd is compatible with Linux distributions like Ubuntu, CentOS, and also Windows.

We can start by updating the package list on Ubuntu:

$ sudo apt update

Subsequently, we can install etcd:

$ sudo apt install etcd

Similarly, on CentOS, we first need to enable the EPEL repository and then install etcd:

$ sudo yum install epel-release
$ sudo yum install etcd

Alternatively, we can visit the official etcd GitHub releases page to download the latest release. Otherwise, we can clone the repo using the following command:

$ git clone -b v3.5.11 https://github.com/etcd-io/etcd.git

For cloning the latest version, we can omit the -b v3.5.11 flag.

Then, we can extract the downloaded archive and navigate to the etcd directory:

$ tar xvf etcd-v3.5.11-linux-amd64.tar.gz
$ cd etcd

Next, we can run the build script:

$ ./build.sh

We can find the binaries under the bin directory. We then need to add the full path to the bin directory to our path:

$ export PATH="$PATH:`pwd`/bin"

Here, pwd is the UNIX command that gets us the full path name of the current directory. Finally, we can ensure that our PATH contains etcd by checking the version:

$ etcd --version

6. Configuration Using  the Config File

We have multiple options to configure etcd. However, in this tutorial, we’ll create a configuration file with basic settings.

The etcd configuration file is a YAML file that contains settings and parameters used to configure the behavior of an etcd node. This file is essential for customizing various aspects of etcd, such as network settings, cluster information, authentication, and storage options. Let’s see an example:

# Example etcd-config.yml
# Node name, a unique identifier, in the etcd cluster
name: node-1
# Data directory where etcd will store its data
data-dir: /var/lib/etcd/default.etcd
# Listen addresses for client communication
listen-client-urls: http://127.0.0.1:2379,http://<NODE-IP>:2379
# Advertise addresses for client communication
advertise-client-urls: http://<NODE-IP>:2379
# Listen addresses for peer communication
listen-peer-urls: http://<NODE-IP>:2380
# Advertise addresses for peer communication
initial-advertise-peer-urls: http://<NODE-IP>:2380
# Initial cluster configuration
initial-cluster: node-1=http://<NODE-IP>:2380,node-2=http://<NODE-IP>:2380
# Unique token for the etcd cluster
initial-cluster-token: etcd-cluster-1
# Initial cluster state (new, existing, or standby)
initial-cluster-state: new
# Enable authentication with a shared secret token
auth-token: "some-secret-token"
# Enable authorization with RBAC
enable-authorization: true
# Enable automatic compaction of the etcd key-value store
auto-compaction-mode: periodic
auto-compaction-retention: "1h"
# Secure communication settings (TLS)
client-transport-security:
  cert-file: /etc/etcd/server.crt
  key-file: /etc/etcd/server.key
  client-cert-auth: true
  trusted-ca-file: /etc/etcd/ca.crt
peer-transport-security:
  cert-file: /etc/etcd/peer.crt
  key-file: /etc/etcd/peer.key
  client-cert-auth: true
  trusted-ca-file: /etc/etcd/ca.crt

Let’s understand a few important notes about this configuration:

Adding TLS Certificates: secure configurations (client-transport-security and peer-transport-security) are optional but recommended for production deployments, providing encrypted communication.

Adding RBAC: Role-Based Access Control adds a layer of security by controlling access to etcd operations based on user roles and permissions.

Enabling auto-compaction: Helps manage the size of the etcd data store by periodically (hourly) removing unnecessary data.

Finally, we should ensure that we customize the configuration file based on our specific requirements and security considerations. After editing the file, we can restart the etcd service for the changes to take effect.

7. Starting and Interacting With etcd

We can start etcd with the specified configuration using the following command:

$ ./etcd --config-file=etcd-config.yml

Further, we can interact with etcd using the etcdctl command-line tool that’s designed for interacting with and managing an etcd cluster. It facilitates administrators and developers in executing various operations on an etcd cluster directly from the command line.

Let’s understand with a few examples:

We can set a key-value pair as:

$ etcdctl put mykey "Hello, etcd!"

Here, mykey is the key, and “Hello, etcd!” is the corresponding value. Subsequently, we can retrieve the value of mykey as:

$ etcdctl get mykey
mykey
Hello, etcd!

To watch changes to mykey, we can simply do:

$ etcdctl watch mykey

Watching a key in etcd allows us to receive real-time notifications about changes to the key, whether the value is modified or the key is deleted. Watch events provide details about the nature of the change, enabling applications to react dynamically to the updates in the etcd key-value store.

It’s important to note that watching a key doesn’t prevent it from being deleted. Watches are mechanisms for observing changes, not for controlling or restricting them.

Finally, we can use the following command to check the health of the etcd cluster:

$ etcdctl endpoint health

If we’re working with a secured etcd cluster, then we may need to provide additional authentication and security options, such as specifying the –cacert, –cert, and –key flags to point to the certificate and key files while checking the health.

8. Code Example

To interact with etcd using Java, we can use a Java client library like jetcd or etcd4j. In our example, we’ll use jetcd since it’s the official Java client for etcd v3.

jetcd is built upon Java 11. It facilitates all key-based etcd requests and offers SSL security. Moreover, it allows the definition of multiple connection URLs and provides both synchronous and asynchronous APIs, giving us flexibility in choosing the programming model that best fits our application.

We can add the jetcd-core dependency to our project as:

<dependency>
    <groupId>io.etcd</groupId>
    <artifactId>jetcd-core</artifactId>
    <version>0.7.7</version>
</dependency>

Now, let’s see a basic example demonstrating the put, retrieve, and delete operations using jetcd:

public class JetcdExample {
    public static void main(String[] args) {
        String etcdEndpoint = "http://localhost:2379";
        ByteSequence key = ByteSequence.from("/mykey".getBytes());
        ByteSequence value = ByteSequence.from("Hello, etcd!".getBytes());
        try (Client client = Client.builder().endpoints(etcdEndpoint).build()) {
            KV kvClient = client.getKVClient();
            
            // Put a key-value pair
            kvClient.put(key, value).get();
            
            // Retrieve the value using CompletableFuture
            CompletableFuture<GetResponse> getFuture = kvClient.get(key);
            GetResponse response = getFuture.get();
            
            // Delete the key
            kvClient.delete(key).get();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

9. Comparison With Apache Zookeeper and Consul

As distributed system tools, etcd, Apache Zookeeper, and Consul are designed to manage configurations, coordinate, and provide a reliable foundation for building distributed applications. However, they have significant differences in their design philosophies, architecture, and use cases:

Choosing between etcd, Apache ZooKeeper, and Consul depends on specific project needs.

etcd, with its simplicity and Cloud Native Computing Foundation (CNCF) support, suits cloud-native environments like Kubernetes. Apache ZooKeeper, a robust choice for large-scale deployments, offers strong consistency but comes with added complexity. On the other hand, Consul, known for simplicity and effective service discovery, integrates seamlessly with the HashiCorp stack.

Security, ease of use, and integration requirements play pivotal roles in the decision-making process. Each tool has its strengths, therefore making an informed selection is crucial for us based on the desired features and use cases.

10. Conclusion

In this article, we’ve explored etcd comprehensively, discussing its foundational concepts, critical features, and practical applications. The quick start guide will help us set up etcd quickly and interact with it programmatically. Additionally, the comparison with other distributed key-value stores highlights the unique strengths of etcd, making it a reliable choice for various distributed system scenarios.

Understanding distributed reliable key-value stores, the criticality of data in distributed systems, and the capabilities of etcd will help us make informed decisions when designing and implementing distributed applications. Finally, as the backbone of many distributed systems, etcd’s simplicity, consistency, and high availability make it a valuable tool for developers navigating the complexities of distributed environments.

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

       

1. Overview

When we work in Java, String manipulation and comparison are everyday tasks.

In this quick tutorial, let’s delve into an interesting problem: checking if a String equals its mirror reflection.

2. Introduction to the Problem

It’s a common misconception that obtaining the mirror reflection of a String simply involves reversing its order. Take, for instance, the String “ALL”. Intuitively, one might expect its mirror reflection to be “LLA”. Yet, upon closer examination using an actual mirror, we discover that “LLA” doesn’t quite match the mirrored version of “ALL“.

The key misunderstanding lies in the fact that every individual character within a String undergoes a reversal in its mirror reflection. Thus, the mirror reflection of “ALL” actually appears as “⅃⅃A”.

Characters can be categorized as symmetric or asymmetric based on reversed behavior. A symmetric character is one that remains unchanged when reversed, such as ‘A’, ‘O’, ‘o’, ‘V’, ‘v’, ‘M’, ‘8’, ‘+’, ‘-‘, and so on. Conversely, an asymmetric character differs from its reversed form, exemplified by ‘L’, ‘S’, ‘p’, ‘h’, ‘/’, ‘3’, etc.

So, when we say a String equals its mirror reflection, it has two requirements:

• The String only contains symmetric characters.
• The given String must equal its reversed value. In other words, the String must be a palindrome, for example “MUM“

For simplicity, we’ll only check String values consisting of uppercase English letters as examples in this tutorial. Then, these are the symmetric uppercase characters we need to check:

final static Set<Character> SYMMETRIC_LETTERS = Set.of('A', 'H', 'I', 'M', 'O', 'T', 'U', 'V', 'W', 'X', 'Y');

Next, let’s explore how to perform the String mirror reflection check.

3. The Idea to Solve the Problem: Combining the Two Checks

Now that we understand the problem’s two requirements, a straightforward idea to solve the problem is creating a method to combine the symmetric character check and palindrome String check:

boolean isMirrorImageEqual(String input) {
    return containsOnlySymmetricLetters(input) && isPalindrome(input);
}

Next, let’s tackle this step by step.

4. Implementing the containsOnlySymmetricLetters() Method

As we have defined the symmetric letters in a Set, we need to examine whether SYMMETRIC_LETTERS contains each character in the given String:

boolean containsOnlySymmetricLetters(String input) {
    Set<Character> characterSet = input.chars()
      .mapToObj(c -> (char) c)
      .collect(Collectors.toSet());
    characterSet.removeAll(SYMMETRIC_LETTERS);
    return characterSet.isEmpty();
}

As the code above shows, we perform this check in three steps:

• Convert the input String into a Set<Character> named characterSet
• Remove all required symmetric letters from characterSet
• Check if characterSet is empty after the removal
• If the set is empty, it means it only contained symmetric characters

Next, let’s implement the isPalindrome() method.

5. Implementing the isPalindrome() Method

There are different ways to check if a String is a palindrome in Java. Let’s take a straightforward solution to do the job:

boolean isPalindrome(String input) {
    String reversed = new StringBuilder(input).reverse()
      .toString();
    return input.equals(reversed);
}

As we can see, we check if the input String and the reversed input are equal to determine whether input is a palindrome.

6. Testing the Solution

Now, both building blocks of isMirrorImageEqual() are in place. Finally, let’s create a test to verify if this method solves our problem:

assertFalse(isMirrorImageEqual("LOL"));
assertFalse(isMirrorImageEqual("AXY"));
assertFalse(isMirrorImageEqual("HUHU"));
 
assertTrue(isMirrorImageEqual(""))
assertTrue(isMirrorImageEqual("AAA"));
assertTrue(isMirrorImageEqual("HUH"));
assertTrue(isMirrorImageEqual("HIMMIH"));
assertTrue(isMirrorImageEqual("HIMIH"));

As we can see, we test the method with various input String values, and our solution works as expected.

7. Conclusion

In this article, we first discussed the characteristics of a String‘s mirror reflection. Then, we explored a solution to check whether a given String and its mirror reflection are equal.

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

       

1. Overview

Introduced in Java 8, the Stream API has revolutionized how developers work with object collections. Streams provide powerful operations to process and manipulate data concisely and declaratively. One common task when working with streams is to extract a range of items from the stream based on certain criteria or indices. In this blog post, we’ll explore how to efficiently retrieve a range of items from a stream in Java.

2. Understanding Streams in Java

Before extracting a range of items from a stream, let’s have a quick overview of streams in Java. Streams represent elements that can be processed in a functional style. They enable developers to perform operations such as filtering, mapping, sorting, and reducing data collection.

Streams are composed of three parts:

• Source: The source of elements, such as a collection, an array, or an I/O channel
• Intermediate Operations: Operations that transform the stream into another stream, such as filtering or mapping
• Terminal Operations: Operations that produce a result or a side-effect, such as forEach or collect

3. Getting a Range of Items from a Stream

To extract a range of items from a stream in Java, we have several approaches at our disposal. Let’s explore some of them.

3.1. Using the skip() and limit() Operations

The skip() and limit() operations are often combined to extract a range of items from a stream. Let’s see them in action:

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
List<Integer> range = numbers.stream() 
        .skip(2) 
        .limit(5) 
        .collect(Collectors.toList());

In this example, we skip the first two elements using the skip() operation and then limit the stream to the next five elements using the limit() operation. Therefore, our result is:

3, 4, 5, 6, 7

3.2. Using Collectors.collectingAndThen()

We can use Collectors.collectingAndThen() along with Collectors.toList() to collect the elements into a list and then manipulate the list as needed. Let’s see an example:

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
List<Integer> range = numbers.stream()
        .filter(n -> n >= 3 && n <= 7)
        .collect(Collectors.collectingAndThen(Collectors.toList(), Collections::unmodifiableList));

In this example, we filter the stream to include only elements between 3 and 7, and then we collect them into an unmodifiable list using Collectors.collectingAndThen(). Therefore, our result is:

3, 4, 5, 6, 7

4. Conclusion

The Stream API in Java provides powerful capabilities for processing and manipulating data. Extracting a range of items from a stream allows developers to efficiently work with large datasets and perform targeted operations on subsets of the data.

By leveraging operations like skip(), limit(), and collectingAndThen(), developers can easily extract the desired range of elements from streams or collections. Understanding these techniques equips Java developers with the tools to write cleaner, more concise code that efficiently handles data processing tasks.

As usual, the source code for all of these examples is available over on GitHub.

       

1. Overview

Database functions are essential components in database management systems, enabling the encapsulation of logic and execution within the database. They facilitate efficient data processing and manipulation.

In this tutorial, we’ll explore various approaches to calling custom database functions within JPA and Spring Boot applications.

2. Project Setup

We’ll demonstrate the concepts in the subsequent sections using the H2 database.

Let’s include Spring Boot Data JPA and H2 dependencies in our pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
    <version>3.2.2</version>
</dependency>
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>2.2.224</version>
</dependency>

3. Database Functions

Database functions are database objects that perform specific tasks by executing a set of SQL statements or operations within the database. This enhances the performance when the logic is data intensive. Although database functions and stored procedures operate similarly, they exhibit differences.

3.1. Functions vs. Stored Procedures

While different database systems may have specific differences between them, the major differences between them can be summarized in the following table:

3.2. H2 Function

To illustrate invoking database functions from JPA, we’ll create a database function in H2 to illustrate how to invoke it from JPA. The H2 database function is simply embedded Java source code that will be compiled and executed:

CREATE ALIAS SHA256_HEX AS '
    import java.sql.*;
    @CODE
    String getSha256Hex(Connection conn, String value) throws SQLException {
        var sql = "SELECT RAWTOHEX(HASH(''SHA-256'', ?))";
        try (PreparedStatement stmt = conn.prepareStatement(sql)) {
            stmt.setString(1, value);
            ResultSet rs = stmt.executeQuery();
            if (rs.next()) {
                return rs.getString(1);
            }
        }
        return null;
    }
';

This database function SHA256_HEX accepts a single input argument as a string, processing it through the SHA-256 hashing algorithm, and subsequently returns the hexadecimal representation of its SHA-256 hash.

4. Invoking as a Stored Procedure

The first approach is to invoke database functions similar to stored procedures within JPA. We accomplish it by annotating the entity class by @NamedStoredProcedureQuery. This annotation allows us to specify the metadata of a stored procedure directly within the entity class.

Here’s an example of the Product entity class with the defined stored procedure SHA256_HEX:

@Entity
@Table(name = "product")
@NamedStoredProcedureQuery(
  name = "Product.sha256Hex",
  procedureName = "SHA256_HEX",
  parameters = @StoredProcedureParameter(mode = ParameterMode.IN, name = "value", type = String.class)
)
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "product_id")
    private Integer id;
    private String name;
    // constructor, getters and setters
}

In the entity class, we annotate our Product entity class with @NamedStoredProcedureQuery. We assign Product.sha256Hex as the name of the named stored procedure.

In our repository definition, we annotate the repository method with the @Procedure and refer to the name of our @NamedStoredProcedureQuery. This repository method takes a string argument, then supplies it to the database function, and returns the result of the database function call.

public interface ProductRepository extends JpaRepository<Product, Integer> {
    @Procedure(name = "Product.sha256Hex")
    String getSha256HexByNamed(@Param("value") String value);
}

We’ll see Hibernate invoking it like calling a stored procedure from the Hibernate log upon execution:

Hibernate: 
    {call SHA256_HEX(?)}

@NamedStoredProcedureQuery is primarily designed for invoking stored procedures. The database functions can be invoked alone, similar to stored procedures as well. However, it may not be ideal for database functions used in conjunction with select queries.

5. Native Query

Another approach to call database functions is through native queries. There are two different ways to invoke database functions using a native query.

5.1. Native Call

From the previous Hibernate log, we can see that Hibernate executed a CALL command. Likewise, we can use the same command to invoke our database function natively:

public interface ProductRepository extends JpaRepository<Product, Integer> {
    @Query(value = "CALL SHA256_HEX(:value)", nativeQuery = true)
    String getSha256HexByNativeCall(@Param("value") String value);
}

The execution result will be the same as we saw in the example of using @NamedStoredProcedureQuery.

5.2. Native Select

As we depicted before, we couldn’t use it in conjunction with select queries. We’ll switch it to a select query and apply the function to a column value from a table. In our example, we define a repository method that uses a native select query to invoke our database function on the name column of the Product table:

public interface ProductRepository extends JpaRepository<Product, Integer> {
    @Query(value = "SELECT SHA256_HEX(name) FROM product", nativeQuery = true)
    String getProductNameListInSha256HexByNativeSelect();
}

Upon execution, we can get the identical query from the Hibernate log as we defined because we defined it as a native query:

Hibernate: 
    SELECT
        SHA256_HEX(name) 
    FROM
        product

6. Function Registration

Function registration is a Hibernate process of defining and registering custom database functions that can be used within JPA or Hibernate queries. This helps Hibernate translate the custom functions into the corresponding SQL statements.

6.1. Custom Dialect

We can register custom functions by creating a custom dialect. Here’s the custom dialect class that extends the default H2Dialect and registers our function:

public class CustomH2Dialect extends H2Dialect {
    @Override
    public void initializeFunctionRegistry(FunctionContributions functionContributions) {
        super.initializeFunctionRegistry(functionContributions);
        SqmFunctionRegistry registry = functionContributions.getFunctionRegistry();
        TypeConfiguration types = functionContributions.getTypeConfiguration();
        new PatternFunctionDescriptorBuilder(registry, "sha256hex", FunctionKind.NORMAL, "SHA256_HEX(?1)")
          .setExactArgumentCount(1)
          .setInvariantType(types.getBasicTypeForJavaType(String.class))
          .register();
    }
}

When Hibernate initializes a dialect, it registers available database functions to the function registry via initializeFunctionRegistry(). We override the initializeFunctionRegistry() method to register additional database functions that the default dialect doesn’t include.

PatternFunctionDescriptorBuilder creates a JPQL function mapping that maps our database functions SHA256_HEX to a JPQL function sha256Hex and registers the mapping to the function registry. The argument ?1 indicates the first input argument for the database function.

6.2. Hibernate Configuration

We have to instruct Spring Boot to adopt the CustomH2Dialect instead of the default H2Dialect. Here the HibernatePropertiesCustomizer that comes in place. It’s an interface provided by Spring Boot to customize properties used by Hibernate.

We override the customize() method to put an additional property to indicate we’ll use CustomH2Dialect:

@Configuration
public class CustomHibernateConfig implements HibernatePropertiesCustomizer {
    @Override
    public void customize(Map<String, Object> hibernateProperties) {
        hibernateProperties.put("hibernate.dialect", "com.baeldung.customfunc.CustomH2Dialect");
    }
}

Spring Boot automatically detects and applies the customization during the application start-up.

6.3. Repository Method

In our repository, we can now use the JPQL query that applies the newly defined function sha256Hex instead of the native query:

public interface ProductRepository extends JpaRepository<Product, Integer> {
    @Query(value = "SELECT sha256Hex(p.name) FROM Product p")
    List<String> getProductNameListInSha256Hex();
}

When we check the Hibernate log upon the execution, we see that Hibernate correctly translated the JPQL sha256Hex function to our database function SHA256_HEX:

Hibernate: 
    select
        SHA256_HEX(p1_0.name) 
    from
        product p1_07'

7. Conclusion

In this article, we conducted a brief comparison between database functions and stored procedures. Both offer a powerful means to encapsulate logic and execute within the database.

Moreover, we have explored different approaches to call database functions, including utilizing @NamedStoredProcedureQuery annotation, native queries, and function registration via custom dialects. By incorporating database functions into repository methods, we can easily build database-driven applications.

As usual, the examples providing a practical resource of the concepts discussed are available over on GitHub.

       

1. Introduction

In the CompletableFuture framework, thenApply() and thenApplyAsync() are crucial methods that facilitate asynchronous programming.

In this tutorial, we’ll delve into the differences between thenApply() and thenApplyAsync() in CompletableFuture. We’ll explore their functionalities, use cases, and when to choose one over the other.

2. Understanding thenApply() and thenApplyAsync()

CompletableFuture provides the methods thenApply() and thenApplyAsync() for applying transformations to the result of a computation. Both methods enable chaining operations to be performed on the result of a CompletableFuture.

2.1. thenApply()

thenApply() is a method used to apply a function to the result of a CompletableFuture when it completes. It accepts a Function functional interface, applies the function to the result, and returns a new CompletableFuture with the transformed result.

2.2. thenApplyAsync()

thenApplyAsync() is a method that executes the provided function asynchronously. It accepts a Function functional interface and an optional Executor and returns a new CompletableFuture with the asynchronously transformed result.

3. Execution Thread

The primary difference between thenApply() and thenApplyAsync() lies in their execution behavior.

3.1. thenApply()

By default, thenApply() method executes the transformation function using the same thread that completed the current CompletableFuture. This means that the execution of the transformation function may occur immediately after the result becomes available. This can potentially block the thread if the transformation function is long-running or resource-intensive.

However, if we call thenApply() on a CompletableFuture that hasn’t yet completed, it executes the transformation function asynchronously in another thread from the executor pool.

Here’s a code snippet illustrating thenApply():

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> 5);
CompletableFuture<String> thenApplyResultFuture = future.thenApply(num -> "Result: " + num);
String thenApplyResult = thenApplyResultFuture.join();
assertEquals("Result: 5", thenApplyResult);

In this example, if the result is already available and the current thread is compatible, thenApply() might execute the function synchronously. However, it’s important to note that CompletableFuture intelligently decides whether to execute synchronously or asynchronously based on various factors, such as the availability of the result and the threading context.

3.2. thenApplyAsync()

In contrast, thenApplyAsync() guarantees asynchronous execution of the provided function by utilizing a thread from an executor pool, typically the ForkJoinPool.commonPool(). This ensures that the function is executed asynchronously and may run in a separate thread, preventing any blocking of the current thread.

Here’s how we can use thenApplyAsync():

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> 5);
CompletableFuture<String> thenApplyAsyncResultFuture = future.thenApplyAsync(num -> "Result: " + num);
String thenApplyAsyncResult = thenApplyAsyncResultFuture.join();
assertEquals("Result: 5", thenApplyAsyncResult);

In this example, even if the result is immediately available, thenApplyAsync() always schedules the function for asynchronous execution on a separate thread.

4. Control Thread

While both thenApply() and thenApplyAsync() enable asynchronous transformations, they differ in their support for specifying custom executors and thus controlling the execution thread.

4.1. thenApply()

The thenApply() method doesn’t directly support specifying a custom executor to control the execution thread. It relies on the default behavior of CompletableFuture, which may execute the transformation function on the same thread that completed the previous stage, typically a thread from the common pool.

4.2. thenApplyAsync()

In contrast, thenApplyAsync() allows us to explicitly specify an executor to control the execution thread. By providing a custom executor, we can dictate where the transformation function executes, enabling more precise thread management.

Here’s how we can use a custom executor with thenApplyAsync():

ExecutorService customExecutor = Executors.newFixedThreadPool(4);
CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> {
    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return 5;
}, customExecutor);
CompletableFuture<String> resultFuture = future.thenApplyAsync(num -> "Result: " + num, customExecutor);
String result = resultFuture.join();
assertEquals("Result: 5", result);
customExecutor.shutdown();

In this example, a custom executor with a fixed thread pool size of 4 is created. The thenApplyAsync() method then uses this custom executor, providing control over the execution thread for the transformation function.

5. Exception Handling

The key difference in exception handling between thenApply() and thenApplyAsync() lies in when and how the exception becomes visible.

5.1. thenApply()

If the transformation function provided to thenApply() throws an exception, the thenApply() stage immediately completes the CompletableFuture exceptionally. This exceptional completion carries the thrown exception within a CompletionException, wrapping the original exception.

Let’s illustrate this with an example:

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> 5);
CompletableFuture<String> resultFuture = future.thenApply(num -> "Result: " + num / 0);
assertThrows(CompletionException.class, () -> resultFuture.join());

In this example, we’re trying to divide 5 by 0, which results in an ArithmeticException being thrown. This CompletionException is directly propagated to the next stage or the caller, meaning any exception within the function is immediately visible for handling. So, if we try to access the result using methods like get(), join(), or thenAccept(), we encounter CompletionException directly:

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> 5);
CompletableFuture<String> resultFuture = future.thenApply(num -> "Result: " + num / 0);
try {
    // Accessing the result using join()
    String result = resultFuture.join();
    assertEquals("Result: 5", result);
} catch (CompletionException e) {
    assertEquals("java.lang.ArithmeticException: / by zero", e.getMessage());
}

In this example, the exception thrown during the function passed to thenApply(). The stage recognizes the problem and wraps the original exception in a CompletionException, allowing us to handle it further down the line.

5.2. thenApplyAsync()

While the transformation function runs asynchronously, any exception within it isn’t directly propagated to the returned CompletableFuture. The exception isn’t immediately visible when we call methods like get(), join(), or thenAccept(). These methods block until the asynchronous operation finishes, potentially leading to deadlock if not handled correctly.

To handle exceptions in thenApplyAsync(), we must use dedicated methods like handle(), exceptionally(), or whenComplete(). These methods allow us to intercept and process the exception when it occurs asynchronously.

Here is the code snippet to demonstrate explicit handling with handle:

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> 5);
CompletableFuture<String> thenApplyAsyncResultFuture = future.thenApplyAsync(num -> "Result: " + num / 0);
String result = thenApplyAsyncResultFuture.handle((res, error) -> {
      if (error != null) {
          // Handle the error appropriately, e.g., return a default value
          return "Error occurred";
      } else {
          return res;
      }
  })
  .join(); // Now join() won't throw the exception
assertEquals("Error occurred", result);

In this example, even though an exception occurred within thenApplyAsync(), it isn’t directly visible in the resultFuture. The join() method blocks and eventually unwraps the CompletionException, revealing the original ArithmeticException.

6. Use Case

In this section, we’ll explore common use cases for thenApply() and thenApplyAsync() methods in CompletableFuture.

6.1. thenApply()

The thenApply() method is particularly useful in the following scenarios:

• Sequential Transformation: When there is a need to sequentially apply a transformation to the result of a CompletableFuture. This could involve tasks such as converting a numeric result to a string or performing calculations based on the result.
• Lightweight Operations: It’s well-suited for executing small, quick transformations that won’t impose significant blocking on the calling thread. Examples include converting numbers to strings, performing calculations based on the result, or manipulating data structures.

6.2. thenApplyAsync()

On the other hand, the thenApplyAsync() method is appropriate in the following situations:

• Asynchronous Transformation: When there’s a requirement to apply a transformation asynchronously, possibly leveraging multiple threads for parallel execution. For instance, in a web application where users upload images for editing, employing asynchronous transformation with CompletableFuture can be beneficial for concurrently applying resizing, filters, and watermarks, thus enhancing processing efficiency and user experience.
• Blocking Operations: In cases where the transformation function involves blocking operations, I/O operations, or computationally intensive tasks, thenApplyAsync() becomes advantageous. By offloading such computations to a separate thread, helps prevent blocking the calling thread, thereby ensuring smoother application performance.

7. Summary

Here’s a summary table comparing the key differences between thenApply() and thenApplyAsync().

8. Conclusion

In this article, we’ve explored the functionalities and differences between the thenApply() and thenApplyAsync() methods in the CompletableFuture framework.

thenApply() may potentially block the thread, making it suitable for lightweight transformations or scenarios where synchronous execution is acceptable. On the other hand, thenApplyAsync() guarantees asynchronous execution, making it ideal for operations involving potential blocking or computationally intensive tasks where responsiveness is critical.

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

       

1. Overview

In this tutorial, we’ll learn how to check if a string is a rotation of another string.

We’ll briefly discuss what string rotation is. Then, we’ll look at some algorithms to solve the problem with code insight and complexity analysis.

2. Introduction to String Rotation

Before digging into some solutions, let’s discuss string rotation and what we should test for the algorithm.

2.1. String and String Rotation

A string is a sequence of primitive characters, and in Java, it’s wrapped in a String class. Although two strings might be different objects, we can compare their internal characters and check, for example, whether they’re equal or contain common patterns.

A rotation of a string is a string that contains the same characters but in a different order. Specifically, one or more characters are shifted from the original position. For example, the string “cdab” is a rotation of “abcd”. This can be seen in two steps:

• abcd -> dabc shifts the last d to the first position
• dabc -> cdab shifts the last c to the first position

This is done by shifting from the right, but it could be done also from the left.

Notably, we can say that if two strings aren’t the same length, they can’t be one rotation of the other.

2.2. Variable Names

To demonstrate, we’ll always refer to the rotation as the potential string candidate to check whether it’s an actual rotation of an origin.

2.3. Unit Testing

We have only two cases to test whether a string is a rotation. Notably, a string is a rotation of itself. Therefore, we might also want to test that corner case.

3. Rotation Contained in Doubled String

We can naively think that if we double our origin string, at some point, it will contain a rotation. We can picture this intuitively:

3.1. Algorithm

The algorithm is straightforward:

boolean doubledOriginContainsRotation(String origin, String rotation) {
    if (origin.length() == rotation.length()) {
        return origin.concat(origin)
          .contains(rotation);
    }
    return false;
}

3.2. Code Insight

We concatenate the origin with itself, and we check if it contains the potential rotation:

return origin.concat(origin).contains(rotation);

Let’s look at the algorithm complexity:

• Time Complexity: O(n*m) where n is the length of the concatenation and m is the length of the rotation
• Space Complexity: O(n) proportional to the length of the strings

3.3. Unit Tests

Let’s test the rotation contained in the doubled origin string when the rotation is ok. We’ll also test when the origin is the exact string as the rotation:

@Test
void givenDoubledOrigin_whenCheckIfOriginContainsRotation_thenIsRotation() {
    assertTrue(doubledOriginContainsRotation("abcd", "cdab"));
    assertTrue(doubledOriginContainsRotation("abcd", "abcd"));
}

Let’s test when the rotation isn’t contained. We’ll also test when the rotation is a longer string than the origin:

@Test
void givenDoubledOrigin_whenCheckIfOriginContainsRotation_thenNoRotation() {
    assertFalse(doubledOriginContainsRotation("abcd", "bbbb"));
    assertFalse(doubledOriginContainsRotation("abcd", "abcde"));
}

4. Rotation From Common Start With Origin

We can use the previous approach and build a more detailed algorithm.

First, let’s collect all the indexes in the rotation of the starting character of the origin. Finally, we loop over the origin and compare the strings at shifted positions. Let’s picture these steps in more detail:

4.1. Algorithm

Once we know the common characters, we can check whether the strings continue to be equal:

boolean isRotationUsingCommonStartWithOrigin(String origin, String rotation) {
    if (origin.length() == rotation.length()) {
        List<Integer> indexes = IntStream.range(0, origin.length())
          .filter(i -> rotation.charAt(i) == origin.charAt(0))
          .boxed()
          .collect(Collectors.toList());
        for (int startingAt : indexes) {
            if (isRotation(startingAt, rotation, origin)) {
                return true;
            }
        }
    }
    return false;
}
boolean isRotation(int startingAt, String rotation, String origin) {
    for (int i = 0; i < origin.length(); i++) {
        if (rotation.charAt((startingAt + i) % origin.length()) != origin.charAt(i)) {
            return false;
        }
    }
    return true;
}

4.2. Code Insight

There are two main points to focus on. The first is where we collect the indexes:

List<Integer> indexes = IntStream.range(0, origin.length())
  .filter(i -> rotation.charAt(i) == origin.charAt(0))
  .boxed()
  .collect(Collectors.toList());

These are the positions in the rotation where we can find the starting character of the origin.

Then, we loop over the strings and check at shifted positions:

for (int i = 0; i < origin.length(); i++) {
    if (rotation.charAt((startingAt + i) % origin.length()) != origin.charAt(i)) {
        return false;
    }
}

Notably, we use the modulo (%) to return from the first index when we exceed the rotation length.

Let’s look at the algorithm complexity:

• Time Complexity: O(n*m) where n is the length of the origin and m is the number of indexes found
• Space Complexity: O(n)

4.3. Unit tests

Let’s test when the rotation has common starting characters with the origin and the remaining part of the strings are equal:

@Test
void givenOriginAndRotationInput_whenCheckingCommonStartWithOrigin_thenIsRotation() {
    assertTrue(isRotationUsingCommonStartWithOrigin("abcd", "cdab"));
    assertTrue(isRotationUsingCommonStartWithOrigin("abcd", "abcd"));
}

Let’s test when the rotation has common starting characters, but it’s either too long, or the remaining part doesn’t match:

@Test
void givenOriginAndRotationInput_whenCheckingCommonStartWithOrigin_thenNoRotation() {
    assertFalse(isRotationUsingCommonStartWithOrigin("abcd", "bbbb"));
    assertFalse(isRotationUsingCommonStartWithOrigin("abcd", "abcde"));
}

5. Rotation Comparing Prefix and Suffix

If we find a common starting character of origin and rotation, we can also say that our strings will be equal before and after that matching point. For example, our origin string “abcd” has the common c at position 2 with “cdab”. However, prefixes and suffixes will need to be equal accordingly for the remaining portion of the strings:

5.1. Algorithm

Whenever we find a common character, we can then compare the prefix and suffix for those segments of characters remaining, inverting the origin and the rotation:

boolean isRotationUsingSuffixAndPrefix(String origin, String rotation) {
    if (origin.length() == rotation.length()) {
        return checkPrefixAndSuffix(origin, rotation);
    }
    return false;
}
boolean checkPrefixAndSuffix(String origin, String rotation) {
    if (origin.length() == rotation.length()) {
        for (int i = 0; i < origin.length(); i++) {
            if (origin.charAt(i) == rotation.charAt(0)) {
                if (checkRotationPrefixWithOriginSuffix(origin, rotation, i)) {
                    if (checkOriginPrefixWithRotationSuffix(origin, rotation, i)) {
                        return true;
                    }
                }
            }
        }
    }
    return false;
}
boolean checkRotationPrefixWithOriginSuffix(String origin, String rotation, int i) {
    return origin.substring(i)
      .equals(rotation.substring(0, origin.length() - i));
}
boolean checkOriginPrefixWithRotationSuffix(String origin, String rotation, int i) {
    return origin.substring(0, i)
      .equals(rotation.substring(origin.length() - i));
}

5.2. Code Insight

We have two checks to make. First, we compare the rotation prefix with the origin suffix:

return origin.substring(i)
  .equals(rotation.substring(0, origin.length() - i));

Then, we compare the rotation suffix with the origin prefix:

return origin.substring(0, i)
  .equals(rotation.substring(origin.length() - i));

Notably, these checks can be done in any order.

Let’s look at the algorithm complexity:

• Time Complexity: O(n*n) comparing two strings of length n
• Space Complexity: O(n)

5.3. Unit Tests

Let’s test when the rotation has equal suffix and prefix with the origin given a common character:

@Test
void givenOriginAndRotationInput_whenCheckingUsingSuffixAndPrefix_thenIsRotation() {
    assertTrue(isRotationUsingSuffixAndPrefix("abcd", "cdab"));
    assertTrue(isRotationUsingSuffixAndPrefix("abcd", "abcd"));
}

Let’s test when the rotation doesn’t have an equal suffix and prefix with the origin:

@Test
void givenOriginAndRotationInput_whenCheckingUsingSuffixAndPrefix_thenNoRotation() {
    assertFalse(isRotationUsingSuffixAndPrefix("abcd", "bbbb"));
    assertFalse(isRotationUsingSuffixAndPrefix("abcd", "abcde"));
}

6. Rotation Comparing Queue of Characters

Another view of the problem is imagining the two strings as queues. Then, we shift the top character of the rotation into the tail and compare the new queue with the origin. Let’s see a simple picture of the queues:

6.1. Algorithm

We create the two queues. Then, we shift from the top character to the bottom of the rotation while checking if it’s equal to the origin at every step.

boolean isRotationUsingQueue(String origin, String rotation) {
    if (origin.length() == rotation.length()) {
        return checkWithQueue(origin, rotation);
    }
    return false;
}
boolean checkWithQueue(String origin, String rotation) {
    if (origin.length() == rotation.length()) {
        Queue<Character> originQueue = getCharactersQueue(origin);
        Queue<Character> rotationQueue = getCharactersQueue(rotation);
        int k = rotation.length();
        while (k > 0 && null != rotationQueue.peek()) {
            k--;
            char ch = rotationQueue.peek();
            rotationQueue.remove();
            rotationQueue.add(ch);
            if (rotationQueue.equals(originQueue)) {
                return true;
            }
        }
    }
    return false;
}
Queue<Character> getCharactersQueue(String origin) {
    return origin.chars()
      .mapToObj(c -> (char) c)
      .collect(Collectors.toCollection(LinkedList::new));
}

6.2. Code Insight

After creating the queue, what is relevant is how we can assert that our strings are equal:

int k = rotation.length();
while (k > 0 && null != rotationQueue.peek()) {
    k--;
    char ch = rotationQueue.peek();
    rotationQueue.remove();
    rotationQueue.add(ch);
    if (rotationQueue.equals(originQueue)) {
        return true;
    }
}

Moving the top element of the queue to the bottom in constant time gives us a new shifted object to compare with the origin.

Let’s look at the algorithm complexity:

• Time Complexity: O(n*n) worst-case where we loop over the whole queue while comparing with the origin
• Space Complexity: O(n)

6.3. Unit Tests

Let’s test that using queues when shifting the rotation from the top to the tail will match the origin:

@Test
void givenOriginAndRotationInput_whenCheckingUsingQueues_thenIsRotation() {
    assertTrue(isRotationUsingQueue("abcd", "cdab"));
    assertTrue(isRotationUsingQueue("abcd", "abcd"));
}

Let’s test using queues when they won’t be equal:

@Test
void givenOriginAndRotationInput_whenCheckingUsingQueues_thenNoRotation() {
    assertFalse(isRotationUsingQueue("abcd", "bbbb"));
    assertFalse(isRotationUsingQueue("abcd", "abcde"));
}

7. Conclusion

In this article, we saw some algorithms to check whether a string is a rotation of another string. We saw how to search for common characters and assert equality using a doubled-origin string and the contains() string method. Similarly, we can use algorithms to check whether the remaining parts of the string match at shifted positions or using suffixes and prefixes. Finally, we also saw an example using queues and moving the peek to the tail of the rotation until it’s equal to the origin.

       

1. Introduction

In Java programming, we quite often work with data encoding and decoding. Additionally, Base64 encoding is popular and used to convert binary data into ASCII text format.

In this tutorial, we’ll discover techniques that can be used to verify if the given string is base64 encoded in Java.

2. Understanding Base64 Encoding

Base64 is a binary-to-text encoding scheme that encodes binary data into an ASCII string format.

Every group of 3 bytes corresponds to four characters, making the communication process safe since the data will be sent over textual protocols.

3. Using Base64.getDecoder().decode() 

Java provides libraries for the Base64 encoding and decoding tasks in the java.util package. Moreover, the most used class is the Base64 class, part of Java 8.

Let’s demonstrate how to use the Base64 class to check if a string is Base64 encoded:

@Test
public void givenBase64EncodedString_whenDecoding_thenNoException() {
    try {
        Base64.getDecoder().decode("SGVsbG8gd29ybGQ=");
        assertTrue(true);
    } catch (IllegalArgumentException e) {
        fail("Unexpected exception: " + e.getMessage());
    }
}

This test function applies the Base64.getDecoder.decode() method to decode a Base64 encoded string SGVsbG8gd29ybGQ.

If successful, it asserts assertTrue(true), indicating that the string is Base64 encoded. If an unexpected exception occurs (catching IllegalArgumentException), the test fails.

@Test
public void givenNonBase64String_whenDecoding_thenCatchException() {
    try {
        Base64.getDecoder().decode("Hello world!");
        fail("Expected IllegalArgumentException was not thrown");
    } catch (IllegalArgumentException e) {
        assertTrue(true);
    }
}

Same as the previous test method, this one applies the Base64.getDecoder.decode() method to decode a Non-Base64 encoded string Hello World!.

If the test throws the expected (IllegalArgumentException), the test asserts assertTrue(true). Otherwise, the test fails. 

4. Using Regular Expressions

On the other hand, a regular expression-based approach can also be considered for Base64 encoding verification. Simply, we can use a pattern and match it against the desired string.

Let’s see how we can implement this approach: 

@Test
public void givenString_whenOperatingRegex_thenCheckIfItIsBase64Encoded() {
    Pattern BASE64_PATTERN = Pattern.compile(
      "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"
    );
    assertTrue(BASE64_PATTERN.matcher("SGVsbG8gd29ybGQ=").matches());
}

In this test method, we define a regular expression Pattern named BASE64_PATTERN using the Pattern.compile() method to make sure a given string conforms to the Base64 encoding format. After that, we create a Matcher object, which is used to match the input string against the defined pattern. If the entire string matches, it returns true; otherwise, it returns false.

5. Conclusion

In summary, this article delves into several methods for Base64 encoding verification, such as Base64.getDecoder().decode() and regex, serving the overall purpose of building flexibility into the system of encoding verification writers in Java. 

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