1. Introduction

In today’s software landscape, interacting with cloud storage services such as Amazon Simple Storage Service (S3) has become a fundamental aspect of many applications. One common requirement is downloading files stored in S3 using a provided URL.

In this article, we’ll explore a simplified approach to achieve this using Java, Spring Boot, and the AWS SDK for Java.

2. Setup

First, we need to have configured our AWS credentials to access the S3 bucket. This can be done in several ways. For development purposes, we can set our credentials in the application.properties file:

aws.accessKeyId= <your_access_key_id>
aws.secretKey= <your_secret_access_key>
aws.region= <your_region>

Next, let’s include the AWS S3 maven dependency:

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>s3</artifactId>
    <version>${amazon.s3.version}</version>
</dependency>

3. Configuring S3 Client

An S3 client typically refers to software or a library that allows users to interact with Amazon S3. Since we’re using AWS Java SDK, we’ll create the S3 client using Java AWS SDK using the provided API:

S3Client s3Client = S3Client.builder()
    .region(Region.US_EAST_1)
    .credentialsProvider(DefaultCredentialsProvider.create())
    .build();

The S3 client handles authentication and authorization when interacting with Amazon S3. It uses the credentials provided to authenticate requests to the S3 service. In this case, we’re configuring the client with the default credentials provider. This typically looks for credentials in environment variables or a shared credentials file created in our prerequisite setup.

4. Defining Download Service

Let’s define a service that interacts with S3Client for downloads.

Firstly, let’s start with defining the method contract for the service:

public interface FileService {
    FileDownloadResponse downloadFile(String s3url) throws IOException, S3Exception;
}

Now, let’s go through the download steps in sequence.

4.1. Extracting Key And Bucket from URL

In this step, let’s focus on extracting essential information from a valid S3 URL, specifically the bucket name and the object key.

Let’s suppose that we have a file stored in an S3 bucket called “baeldung” with the following path: “path/to/my/s3article.txt“. This represents a hierarchical structure within the S3 bucket, where the object “s3article.txt” is nested within directories “path“, “to“, and “my“.

To extract this information programmatically, we’ll decode the S3 URL into its components using Java’s URI class. Then, we’ll separate the hostname (the bucket name) and the path (the object key):

URI uri = new URI(s3Url);
String bucketName = uri.getHost();
String objectKey = uri.getPath()
    .substring(1);

Considering the earlier example, we’ll have the URI “s3://baeldung/path/to/my/s3article.txt“, we’ll extract the bucket name to be “baeldung“. The object key, representing the path within the bucket, would be “path/to/my/s3article.txt“. Importantly here, By using substring(1), we’ll remove the leading “/” character, resulting in the object key being  “path/to/my/s3article.txt, which is the desired format for S3 object keys.

In summary, here we can identify the location of the file within the S3 bucket, enabling us to construct requests and perform operations on the desired object next.

4.2. Building GetObjectRequest

Now, let’s build a GetObjectRequest using the AWS SDK:

GetObjectRequest getObjectRequest = GetObjectRequest.builder()
    .bucket(bucketName) 
    .key(objectKey)
    .build();

GetObjectRequest has the information needed to retrieve an object from S3, such as the bucket name and the key of the object to retrieve. It also allows developers to specify additional parameters like version ID, range, response headers, etc., to customize the behavior of the object retrieval process.

4.3. Sending GetObjectRequest

With the GetObjectRequest prepared, we’ll send it to Amazon S3 using the configured S3Client to retrieve the object data:

ResponseInputStream<GetObjectResponse> responseInputStream = s3ResponseReader.readResponse(getObjectRequest);
GetObjectResponse getObjectResponse = responseInputStream.response();

4.4. Response Data and MetaData

After receiving the response from Amazon S3 as ResponseInputStream<GetObjectResponse>, we’ll extract the file content with the associated metadata.

Let’s extract the file content as a byte array first:

byte[] fileContent = IOUtils.toByteArray(responseInputStream);

Next, let’s inspect some of the useful metadata using the response:

// Get object metadata
String contentType = getObjectResponse.contentType();         
String contentDisposition =  getObjectResponse.contentDisposition()
String key = getObjectRequest.key();
String filename = extractFilenameFromKey(key);
String originalFilename = contentDisposition == null ? filename : contentDisposition.substring(contentDisposition.indexOf("=")+1);

Some metadata will be required when sending the response back to the client. We’ll create an abstraction FileDownloadResponse that encapsulates file content as bytes, contentType, and originalFilename:

@Builder
@Data
@RequiredArgsConstructor
public class FileDownloadResponse {
private final byte[] fileContent;
private final String originalFilename;
private final String contentType;
}

If we wish to perform integration tests, we can consider mocking S3 using Test Containers.

5. Conclusion

In this article, we’d a quick look at how we can download a file from S3 using the provided URL. We used AWS Java SDK consisting of S3 Client to enable users to access and download S3 resources securely. It simplifies managing S3 buckets and objects by providing a convenient and consistent API for performing various operations on S3 resources.

As always, the full implementation of this article can be found over on GitHub.

       

1. Introduction

Determining the length of the longest symmetric substring poses a common challenge in string manipulation tasks.

In this tutorial, we’ll discuss two Java approaches for efficiently solving this problem.

2. Understanding Symmetric Substrings

3. Symmetric Substring Expansion Approach

This approach utilizes a sliding window technique to identify the longest symmetric substring within the given string efficiently. Essentially, the algorithm iterates through the string, expanding from the middle while ensuring symmetry.

Let’s delve into the implementation:

private int findLongestSymmetricSubstringUsingSymmetricApproach(String str) {
    int maxLength = 1;
    // Approach implementation
}

In this method, we initialize maxLength to 1, representing the default length of a palindrome substring. Then, we’ll iterate over all possible substrings in the input string as follows:

for (int i = 0; i < str.length(); i++) {
    for (int j = i; j < str.length(); j++) {
        int flag = 1;
        for (int k = 0; k < (j - i + 1) / 2; k++) {
            if (str.charAt(i + k) != str.charAt(j - k)) {
                flag = 0;
                break;
            }
        }
        if (flag != 0 && (j - i + 1) > maxLength) {
            maxLength = j - i + 1;
        }
    }
}

Within each substring, we utilize a nested loop to compare characters from both ends towards the center, checking for symmetry. Moreover, if a substring is found to be symmetric (flag is not 0) and its length exceeds maxLength, we update maxLength with the new length.

Finally, we’ll return the maximum length of a symmetric substring found in the input string as follows:

return maxLength;

4. Using the Brute Force Approach

The brute-force method provides a straightforward solution to the problem. Here’s how we can implement this approach:

private int findLongestSymmetricSubstringUsingBruteForce(String str) {
    if (str == null || str.length() == 0) {
        return 0;
    }
    int maxLength = 0;
    for (int i = 0; i < str.length(); i++) {
        for (int j = i + 1; j <= str.length(); j++) {
            String substring = str.substring(i, j);
            if (isPalindrome(substring) && substring.length() > maxLength) {
                maxLength = substring.length();
            }
        }
    }
    return maxLength;
}

Here, we exhaustively examine all possible substrings within the input string to identify potential palindromic substrings. Additionally, this process involves iterating through each character of the string, considering it as a potential starting point for a substring.

For each starting position, the method iterates through subsequent characters to construct substrings of varying lengths.

Once we construct a substring, we pass it to the isPalindrome() method to determine whether it is a palindrome as follows:

private boolean isPalindrome(String str) {
    int left = 0;
    int right = str.length() - 1;
    while (left < right) {
        if (s.charAt(left) != s.charAt(right)) {
            return false;
        }
        left++;
        right--;
    }
    return true;
}

This method scrutinizes the substring by comparing characters from both ends toward the center, ensuring that the characters mirror each other symmetrically.

If the substring passes the palindrome test and its length surpasses the current maxLength, it is deemed a candidate for the longest palindrome substring. In this case, the method updates the maxLength variable to reflect the new maximum length.

5. Conclusion

In this article, we discussed how to handle the symmetric substring expansion methods, highlighting the importance of specific requirements such as input size and computational efficiency.

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

       

1. Introduction

We can use the toString() method in Java to return a string representation of an object. Often, it’s overridden to provide a meaningful description of the object’s state. However, certain fields might be null, and printing them could lead to NullPointerExceptions.

In this tutorial, we’ll explore several approaches to handling this scenario by using default values.

2. An Employee Use Case Scenario

Let’s consider that we develop an application that manages employee records. Each employee has attributes such as name, age, and department:

public class Employee {
    private String name;
    private int age;
    private String department;
    public Employee(String name, int age, String department) {
        this.name = name;
        this.age = age;
        this.department = department;
    }
}

In addition, it’s crucial to clearly and informatively represent each Employee object when displaying employee information.

However, in real-world scenarios, an employee’s name and department attributes may sometimes be null, leading to unexpected behavior if not appropriately handled.

3. Null Check within the toString() Method

One of the simplest approaches is to perform a null check within the toString() method for each field that could potentially be null. If the field is null, we can print a default value instead. Here’s a basic example:

@Override
public String toString() {
    return "Name: " + (name != null ? name : "Unknown") +
      ", Age: " + age +
      ", Department: " + (department != null ? department : "Unknown");
}

In this approach, when a name or department is null, we print “Unknown” instead to prevent displaying null values in the string representation of the Employee object.

4. Using the Optional Class

Java 8 introduced the Optional class, which can be utilized to handle null values more elegantly.

Here’s how it can be done:

@Override
public String toString() {
    return "Name: " + Optional.ofNullable(name).orElse("Unknown") +
      ", Age: " + age +
      ", Department: " + Optional.ofNullable(department).orElse("Unknown");
}

If the name or department is null, we print “Unknown” instead of null using the Optional’s orElse() method.

5. Custom Helper Method

Creating a custom helper method can improve code readability, especially if multiple fields need to be checked for null values. Additionally, this method can encapsulate the null check and default value assignment logic.

Here’s an example:

private String getDefaultIfNull(String value, String defaultValue) {
    return value != null ? value : defaultValue;
}

Here, we create a custom helper method getDefaultIfNull() to handle null values. This method checks if the value is null and returns the default value if it is.

Then, within the toString() method, we utilize the getDefaultIfNull() method to handle null values for each field:

@Override
public String toString() {
    return "Name: " + getDefaultIfNull(name, "Unknown") +
      ", Age: " + age +
      ", Department: " + getDefaultIfNull(department, "Unknown");
}

6. Using the Objects.toString() Method

Java provides a utility method Objects.toString() to handle null values when converting objects to strings:

@Override
public String toString() {
    return "Name: " + Objects.toString(name, "Unknown") +
      ", Age: " + age +
      ", Department: " + Objects.toString(department, "Unknown");
}

In this approach, we utilize the Objects.toString() method to print “Unknown” instead of null if the name or department fields are null.

7. Conclusion

In this article, we discussed overriding the toString() method and handling the potential null within.

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

       

1. Introduction

Understanding how URLs are redirected is crucial in web development and network programming tasks, such as handling HTTP redirects, validating URL redirects, or extracting final destination URLs. In Java, we can accomplish this functionality using HttpURLConnection or HttpClient libraries.

In this tutorial, we’ll explore different approaches to finding the redirected URL of a given URL in Java.

2. Using HttpURLConnection

Java provides the HttpURLConnection class, which allows us to make HTTP requests and handle responses. Also, we can make use of the HttpURLConnection to find the redirected URL of a given URL. Here’s how it can be done:

String canonicalUrl = "http://www.baeldung.com/";
String expectedRedirectedUrl = "https://www.baeldung.com/";
@Test
public void givenOriginalUrl_whenFindRedirectUrlUsingHttpURLConnection_thenCorrectRedirectedUrlReturned() throws IOException {
    URL url = new URL(canonicalUrl);
    HttpURLConnection connection = (HttpURLConnection) url.openConnection();
    connection.setInstanceFollowRedirects(true);
    int status = connection.getResponseCode();
    String redirectedUrl = null;
    if (status == HttpURLConnection.HTTP_MOVED_PERM || status == HttpURLConnection.HTTP_MOVED_TEMP) {
        redirectedUrl = connection.getHeaderField("Location");
    }
    connection.disconnect();
    assertEquals(expectedRedirectedUrl, redirectedUrl);
}

Here, we define the original URL string (canonicalUrl) and the redirected URL (expectedRedirectedUrl). Then, we create an HttpURLConnection object and open a connection to the original URL.

Afterward, we set the instanceFollowRedirects property to true to enable automatic redirection. Upon receiving the response, we examine the status code to determine if redirection occurred. If redirection occurs, we retrieve the redirected URL from the “Location” header.

Finally, we disconnect the connection and assert that the retrieved redirected URL matches the expected one.

3. Using Apache HttpClient

Alternatively, we can use Apache HttpClient, a more versatile HTTP client library for Java. Apache HttpClient provides more advanced features and better support for handling HTTP requests and responses. Here’s how we can find the redirected URL using Apache HttpClient:

@Test
public void givenOriginalUrl_whenFindRedirectUrlUsingHttpClient_thenCorrectRedirectedUrlReturned() throws IOException {
    RequestConfig config = RequestConfig.custom()
      .setRedirectsEnabled(false)
      .build();
    try (CloseableHttpClient httpClient = HttpClients.custom().setDefaultRequestConfig(config).build()) {
        HttpGet httpGet = new HttpGet(canonicalUrl);
        try (CloseableHttpResponse response = httpClient.execute(httpGet)) {
            int statusCode = response.getStatusLine().getStatusCode();
            String redirectedUrl = null;
            if (statusCode == HttpURLConnection.HTTP_MOVED_PERM || statusCode == HttpURLConnection.HTTP_MOVED_TEMP) {
                org.apache.http.Header[] headers = response.getHeaders("Location");
                if (headers.length > 0) {
                    redirectedUrl = headers[0].getValue();
                }
            }
            assertEquals(expectedRedirectedUrl, redirectedUrl);
        }
    }
}

In this test, we begin by configuring the request to deactivate automatic redirection. Subsequently, we instantiate a CloseableHttpClient and dispatch an HttpGet request to the original URL.

Upon obtaining the response, we analyze the status code and headers to ascertain whether redirection occurred. In the event of redirection, we extract the redirected URL from the Location header.

4. Conclusion

In this article, we discussed how handling redirection correctly is essential for building robust web applications that interact with external resources. We’ve explored how to find the redirected URL of a given URL using both HttpURLConnection and Apache HttpClient.

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

       

1. Introduction

When working with MongoDB in Spring Data, the MongoRepository interface provides a simple way to interact with MongoDB collections using built-in methods.

In this quick tutorial, we’ll learn how to use limit and skip in the MongoRepository.

2. Setup

First things first, let’s create a repository called StudentRepository. This is where we’ll store information about students:

public interface StudentRepository extends MongoRepository<Student, String> {}

Then, we add some sample student records to this repository. Think of these like practice data to help us play around and learn:

@Before
public void setUp() {
    Student student1 = new Student("A", "Abraham", 15L);
    Student student2 = new Student("B", "Usman", 30L);
    Student student3 = new Student("C", "David", 20L);
    Student student4 = new Student("D", "Tina", 45L);
    Student student5 = new Student("E", "Maria", 33L);
    studentList = Arrays.asList(student1, student2, student3, student4, student5);
    studentRepository.saveAll(studentList);
}

After that, we will dive into the details of using skip and limit to find specific student information.

3. Using Aggregation Pipeline

An aggregation pipeline is a powerful tool for processing, transforming, and analyzing data. It works by chaining together multiple stages, each performing a specific operation. These operations include filtering, grouping, sorting, pagination, and more.

Let’s apply the limit and skip to a basic example:

@Test
public void whenRetrievingAllStudents_thenReturnsCorrectNumberOfRecords() {
    // WHEN
    List<Student> result = studentRepository.findAll(0L, 5L);
    // THEN
    assertEquals(5, result.size());
}

The above aggregation pipeline skips the specified number of documents and limits the output to the specified number.

@Test
public void whenLimitingAndSkipping_thenReturnsLimitedStudents() {
    // WHEN
    List<Student> result = studentRepository.findAll(3L, 2L);
    // THEN
    assertEquals(2, result.size());
    assertEquals("Tina", result.get(0).getName());
    assertEquals("Maria", result.get(1).getName());
}

We can even apply limit and skip in a complex aggregation pipeline as well:

@Aggregation(pipeline = {
  "{ '$match': { 'id' : ?0 } }",
  "{ '$sort' : { 'id' : 1 } }",
  "{ '$skip' : ?1 }",
  "{ '$limit' : ?2 }"
})
List<Student> findByStudentId(final String studentId, Long skip, Long limit);

Here’s the test:

@Test
public void whenFilteringById_thenReturnsStudentsMatchingCriteria() {
    // WHEN
    List<Student> result = studentRepository.findByStudentId("A", 0L, 5L);
    // THEN
    assertEquals(1, result.size());
    assertEquals("Abraham", result.get(0).getName());
}

4. Using Pageable

In Spring Data, a Pageable is an interface that represents a request to retrieve data in a paginated manner. When querying data from MongoDB collection, a Pageable object allows us to specify parameters such as page number, page size, and sorting criteria. This is particularly useful for displaying large datasets on applications where showing all items at once would be slow.

Let’s explore how defining a repository method with Pageable enables efficient data retrieval:

Page<Student> findAll(Pageable pageable);

Let’s add a test:

@Test
public void whenFindByStudentIdUsingPageable_thenReturnsPageOfStudents() {
    // GIVEN
    Sort sort = Sort.by(Sort.Direction.DESC, "id");
    Pageable pageable = PageRequest.of(0, 5, sort);
    // WHEN
    Page<Student> resultPage = studentRepository.findAll(pageable);
    // THEN
    assertEquals(5, resultPage.getTotalElements());
    assertEquals("Maria", resultPage.getContent().get(0).getName());
}

5. Conclusion

In this short article, we’ve explored the utilization of skip and limit functionalities within MongoRepository. Moreover, we’ve highlighted the utility of Pageable for streamlined pagination and the flexibility of @Aggregation for more control over the query logic or specific filtering needs.

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

       

1. Overview

In this tutorial, we’ll understand why the Easter date is complex to compute. Then, we’ll implement three algorithms to calculate it in Java: the Gauss, Butcher-Meeus, and Conway algorithms.

2. History of the Catholic Easter Sunday

Easter is a holiday that celebrates the resurrection of Jesus Christ from the dead. Easter’s timing was initially tied to the Jewish Passover, as the last supper of Jesus with his disciples was a Passover meal. However, during the first centuries, each Christian community could elect a date to celebrate it, leading to some controversy. The Council of Nicea in 325 finally standardized Easter’s definition: Easter Sunday is the first Sunday following the full moon after the vernal equinox.

Calculating Easter’s date is challenging because it depends on lunar and solar calendars, and lunar cycles don’t match solar ones. Thus, mathematical algorithms came in handy to determine Easter’s date.

3. Algorithms

Let’s point out that all algorithms focus on calculating the Catholic Easter date that uses the Gregorian calendar introduced by Pope Gregory XIII at the end of the 16th century. On the other hand, some churches, like the Russian Orthodox church, still use the Julian calendar to determine Easter’s date.

Now, let’s take a look at each of the algorithms.

3.1. Gauss Algorithm

Gauss, a famous German mathematician, was the first to tackle the problem at the beginning of the 19th century. His algorithm starts with tracking approximately the lunar orbit and then determines the exact offset to obtain a Sunday following the full moon.

Let’s have a look at it:

LocalDate computeEasterDateWithGaussAlgorithm(int year) {
    int a = year % 19;
    int b = year % 4;
    int c = year % 7;
    int k = year / 100;
    int p = (13 + 8*k) / 25;
    int q = k / 4;
    int M = (15 - p + k - q) % 30;
    int N = (4 + k - q) % 7;
    int d = (19*a + M) % 30;
    int e = (2*b + 4*c + 6*d + N) % 7;
        
    if (d==29 && e == 6) {
        return LocalDate.of(year, 4, 19);
    } else if (d==28 && e==6 && ((11*M + 11)%30 < 10)) {
        return LocalDate.of(year, 4, 18);
    }
        
    int H = 22 + d + e;
    if (H <= 31) {
        return LocalDate.of(year, 3, H);
    }
    return LocalDate.of(year, 4, H-31);
}

In this code:

• a represents the Golden Number, indicating the year’s position in the Metonic cycle
• b is associated with leap years, ensuring accurate adjustments given February’s length
• c keeps track of the calendar not having a leap year once a century
• p and q are intermediate variables, and calculating them leads to determining M and N, which represent adjustments regarding the epact, the difference between the lunar and solar years
• d is the number of days from March 21st till the Paschal full moon
  
• e is the number of days between the first day after the Paschal full moon and Easter Sunday

Lastly, there are two exceptions because the Paschal full moon can never occur on April 19th, and in rare cases, when a Metonic cycle would have its preceding full moon on the same day, which is not allowed.

Our method returns a LocalDate, as it’s a natural choice for representing a date without a timezone. Additionally, we can unit-test our method: for instance, with the year 2024, assuming we called our class EasterDateCalculator:

@Test
void givenEasterInMarch_whenComputeEasterDateWithGaussAlgorithm_thenCorrectResult() {
    assertEquals(LocalDate.of(2024, 3, 31), new EasterDateCalculator().computeEasterDateWithGaussAlgorithm(2024));
}

3.2. Butcher-Meeus Algorithm

The origin of this algorithm is surprising: in 1876, an English paper called Nature received a letter from New York containing a method for Easter date calculation. One year later, Butcher, bishop of Meath, proved it was correct. Meeus popularized it in 1991 in his book Astronomical Algorithms.

Nowadays, it’s the most widely used in calendar-related software and applications.

The Butcher-Meeus algorithm enhances Gauss’s original method by incorporating refinements based on improved astronomical data and computational techniques.

Let’s implement it:

LocalDate computeEasterDateWithButcherMeeusAlgorithm(int year) {
    int a = year % 19;
    int b = year / 100;
    int c = year % 100;
    int d = b / 4;
    int e = b % 4;
    int f = (b + 8) / 25;
    int g = (b - f + 1) / 3;
    int h = (19*a + b - d - g + 15) % 30;
    int i = c / 4;
    int k = c % 4;
    int l = (2*e + 2*i - h - k + 32) % 7;
    int m = (a + 11*h + 22*l) / 451;
    int t = h + l - 7*m + 114;
    int n = t / 31;
    int o = t % 31;
    return LocalDate.of(year, n, o+1);
}

In this implementation:

• a is the Golden Number
• b is the secular year
• c is the vintage
• d and e handle leap century adjustments
• f and g relate to the proemptosis, an adjustment in the lunar equation to account for the Metonic’s cycle imperfection
• h represents the epact
• i and k assist in further leap-year adjustments
• l represents the first Sunday of January
• m is the final correcting term that allows us to compute Easter’s month and day

3.3. Conway Algorithm

A British mathematician named John Conway introduced a new original way to calculate Easter’s date in the second half of the 20th century. For this, he introduced the notion of pivotal days, a series of monthly dates that consistently occur on the same weekday, serving as fundamental reference points for calculating significant events.

Let’s code it:

LocalDate computeEasterDateWithConwayAlgorithm(int year) {
    int s = year / 100;
    int t = year % 100;
    int a = t / 4;
    int p = s % 4;
    int x = (9 - 2*p) % 7;
    int y = (x + t + a) % 7;
    int g = year % 19;
    int G = g + 1;
    int b = s / 4;
    int r = 8 * (s + 11) / 25;
    int C = -s + b + r;
    int d = (11*G + C) % 30;
    d = (d + 30) % 30;
    int h = (551 - 19*d + G) / 544;
    int e = (50 - d - h) % 7;
    int f = (e + y) % 7;
    int R = 57 - d - f - h;
        
    if (R <= 31) {
        return LocalDate.of(year, 3, R);
    }
    return LocalDate.of(year, 4, R-31);
}

More precisely, in this code:

• s is the secular year, and t the vintage
• a assists in determining leap years within a century
• x is the secular pivotal day
• y is the current year’s pivotal day
• G denotes the Golden Number
• b relates to metemptosis, a correction to the lunar equation to prevent Easter’s date from falling one day too late
• r is the proemptosis
• C is the secular correction
• d determines the Paschal full moon’s day
• h accounts for epact-related exceptions
• e measures the deviation between the Paschal full moon and the pivotal day
• lastly, f represents the day of the week of the Paschal full moon, allowing us the eventual calculation of Easter’s date

4. Conclusion

In this article, we understood why algorithms are needed to calculate Easter’s date and implemented the three most famous ones. Simplifications of the Gauss and Butcher-Meeus algorithms exist to calculate Easter’s date in the Julian calendar. However, this isn’t the end of the story for churches that still use the Julian calendar. Nearly all countries use the Gregorian calendar, so in the end, they must convert the date to this calendar.

As always, the code is available over on GitHub.

       

1. Spring and Java

>> JEP 473: Stream Gatherers (Second Preview) [openjdk.org]

The second preview of Stream Gatherers in Java 23 — going beyond pre-defined intermediate operations in Stream API

>> Modernizing Testing Practices for Jakarta EE Projects [infoq.com]

Anatomy of testing in modern Jakarta EE applications: guidelines, data-driven, extensive assertions, coverage, and more

>> Spring Framework 6.2.0-M1: all the little things [spring.io]

And some small yet very useful additions in Spring Framework: escaping property placeholders, fallback beans, background initialization, test decorators, and more

Also worth reading:

• >> Calling Gemma with Ollama, TestContainers, and LangChain4j [foojay.io]
• >> Hibernate 6.5.0.CR2 [in.relation.to]
• >> Ensuring the right usage of Java 21 new features [foojay.io]
• >> Getting Started with bld [foojay.io]
• >> Smarter Logging in Spring Boot with AOP [foojay.io]
• >> Hibernate to move to the Commonhaus Foundation [in.relation.to]

Webinars and presentations:

• >> Spring Tips: the Spring Expression Language [spring.io]
• >> Mastering Java Message Service: A Jakarta EE Developer’s Guide [blog.payara.fish]
• >> A Bootiful Podcast: Marit van Dijk, Jetbrains Developer Advocate [spring.io]
• >> Programmer’s Guide to JDK Flight Recorder [inside.java]
• >> Foojay Podcast #47: Artificial Intelligence and Machine Learning with Java [foojay.io]

Time to upgrade:

• >> Hibernate Search 7.1.1.Final/7.0.1.Final/6.2.4.Final are out! [in.relation.to]
• >> Spring Framework 6.1.6, 6.0.19 and 5.3.34 Available Now Including Fixes for CVE-2024-22262 [spring.io]
• >> Kicking off the Spring Framework 6.2 milestone phase [spring.io]
• >> Spring Data 2023.1.5 and 2023.0.11 released [spring.io]
• >> Spring HATEOAS 2.1.5, 2.2.2 and 2.3 RC1 released [spring.io]
• >> Spring for Apache Pulsar 1.0.5 available now as well as 1.1.0-RC1 [spring.io]
• >> Quarkus 3.9.3 released – Maintenance release [quarkus.io]

2. Technical & Musings

>> Dissolving Design Patterns In Design Elements [frankel.ch]

Meet Meta patterns — a means for capturing the essentials of reusable object-oriented design.

Also worth reading:

• >> Using data replication in legacy displacement [martinfowler.com]
• >> Cloud Native Computing Foundation Graduation of CloudEvents: Q&A with Clemens Vasters [infoq.com]
• >> QCon London: Lessons Learned From Building LinkedIn’s AI/ML Data Platform [infoq.com]

3. Pick of the Week

>> What we know about the xz Utils backdoor that almost infected the world [arstechnica.com]

       

1. Introduction

Simple Java Mail is a popular open-source library that simplifies sending emails in Java applications. It provides a user-friendly API compared to the standard JavaMail API, allowing us to focus on the content and recipients of our emails rather than low-level details.

In this tutorial, we’ll explore the process of setting up Simple Java Mail and learn how to send emails, including attachments and HTML content, handle exceptions, and more.

2. Setting up the Project

We start by adding the Simple Java Mail dependency into our project’s configuration file pom.xml:

<dependency>
    <groupId>org.simplejavamail</groupId>
    <artifactId>simple-java-mail</artifactId>
    <version><span class="pl-token">8</span>.<span class="pl-token">7</span>.<span class="pl-token">0</span></version>
</dependency>

3. Sending Email

Let’s start by sending a simple email using Simple Java Mail.

Emails can have two main parts for the body content: plain text and HTML. Plain text refers to the unformatted content that is displayed in most email clients without any special formatting or styling. They’re guaranteed to be readable by all email clients, regardless of their ability to display HTML content.

Here’s a basic example demonstrating how to construct a simple email:

Email email = EmailBuilder.startingBlank()
  .from("sender@example.com")
  .to("recipient@example.com")
  .withSubject("Email with Plain Text!")
  .withPlainText("This is a test email sent using SJM.")
  .buildEmail();

In this example, we use the startingBlank() method in the EmailBuilder class to initialize a new Email object with default values. It provides a starting point for constructing an email message by creating a blank email template without any predefined content or configuration.

Subsequently, we can then gradually fill in this template with the sender, recipient, subject, body, and other attributes using various methods provided by the EmailBuilder class. For instance, the withPlainText() method takes a string argument containing the actual text message we want to include in the email body.

Following this, we utilize MailerBuilder to configure the SMTP server particulars, encompassing the server’s address, port, username, and password. Finally, the Mailer class is used to dispatch the email:

Mailer mailer = MailerBuilder
  .withSMTPServer("smtp.example.com", 25, "username", "password")
  .buildMailer();
mailer.sendMail(email);

Additionally, to send an email to multiple recipients, we can simply specify multiple email addresses separated by commas in the to() method:

Email email = EmailBuilder.startingBlank()
  // ...
  .to("recipient1@example.com, recipient2@example.com, recipient3@example.com")
  // ...
  .buildEmail();

4. Sending Attachments

Adding attachments to an email is straightforward. We can attach files of various types, such as images, documents, or archives, to the email messages using the withAttachment() method of the EmailBuilder class.

Below is an example of using the withAttachment() method to attach a file in our email:

Email email = EmailBuilder.startingBlank()
  .from("sender@example.com")
  .to("recipient@example.com")
  .withSubject("Email with Plain Text and Attachment!")
  .withPlainText("This is a test email with attachment sent using SJM.")
  .withAttachment("important_document.pdf", new FileDataSource("path/to/important_document.pdf"))
  .buildEmail();

In the example, the withAttachment() method takes the filename and a FileDataSource object representing the attachment data. Moreover, if we need to attach multiple files to our email, we can use a list of AttachmentResource objects:

List<AttachmentResource> arList = new ArrayList<>();
arList.add(new AttachmentResource("important_document.pdf", new FileDataSource("path/to/important_document.pdf")));
arList.add(new AttachmentResource("company_logo.png", new FileDataSource("path/to/company_logo.png")));

Instead of using the withAttachment() method, we’ll utilize the withAttachments() method. This method allows us to pass in a collection of attachment resources:

Email email = EmailBuilder.startingBlank()
  // ...
  .withAttachments(arList)
  .buildEmail();

5. Sending HTML Content

Simple Java Mail allows us to send emails with HTML content and embed images directly within the email. This is useful for creating visually appealing and informative emails. To include embedded images in the HTML email content, we need to reference the images using the CID scheme.

This mechanism acts like a unique identifier that connects an image reference in the HTML content to the actual image data attached to the email. Essentially, it tells the email client where to locate the image for proper display.

Here’s how to create an HTML email that includes an image reference using a CID:

String htmlContent = "<h1>This is an email with HTML content</h1>" +
  "<p>This email body contains additional information and formatting.</p>" +
  "<img src=\"cid:company_logo\" alt=\"Company Logo\">";

In this example, the <img> tag references the image using the identifier cid:company_logo. This establishes the link within the HTML content. While constructing the email, we use the withEmbeddedImage() method to associate the image attachment with the chosen identifier company_logo. This ensures it matches the identifier used in the HTML content.

Here’s an example demonstrating how to send an email with HTML content and an embedded image:

Email email = EmailBuilder.startingblank()
  .from("sender@example.com")
  .to("recipient@example.com")
  .withSubject("Email with HTML and Embedded Image!")
  .withHTMLText(htmlContent)
  .withEmbeddedImage("company_logo", new FileDataSource("path/to/company_logo.png"))
  .buildEmail();

The image data itself isn’t directly embedded within the HTML content. It’s typically included as a separate attachment to the email.

It’s also recommended to provide a plain text version alongside the HTML content using withPlainText(). This offers a fallback option for recipients with email clients that don’t support HTML rendering:

Email email = EmailBuilder.startingBlank()
  // ...
  .withHTMLText(htmlContent)
  .withPlainText("This message is displayed as plain text because your email client doesn't support HTML.")
  .buildEmail();...

6. Replying to and Forwarding Emails

Simple Java Mail provides functionalities for constructing email objects for replying to and forwarding existing emails. When replying to an email, the original email is quoted in the body of the reply itself. Similarly, when forwarding an email, the original email is included as a separate body inside the forward.

To reply to an email, we use the replyingTo() method and provide the received email as a parameter. Then, we configure the email as desired and build it using the EmailBuilder:

<span class="hljs-type">Email</span> <span class="hljs-variable">email</span> <span class="hljs-operator">=</span> EmailBuilder
  .replyingTo(receivedEmail)
  .from("sender@example.com")
  .prependText("This is a Reply Email. Original email included below:")
  .buildEmail();

To forward an email, we use the forwarding() method and provide the received email as a parameter. Then, we configure the email as desired, including any additional text, and build it using the EmailBuilder:

<span class="hljs-type">Email</span> <span class="hljs-variable">email</span> <span class="hljs-operator">=</span> EmailBuilder
  .forwarding(receivedEmail)
  .from("sender@example.com")
  .prependText("This is a Forwarded Email. See below email:")
  .buildEmail();

However, it’s important to understand that Simple Java Mail itself cannot directly retrieve emails from the email server. We’ll need to utilize additional libraries like javax.mail to access and retrieve emails for replying or forwarding.

7. Handling Exceptions

When sending emails, it’s crucial to handle exceptions that may occur during the transmission process to ensure robust functionality. Simple Java Mail throws a checked exception called MailException when errors occur while sending emails.

To effectively handle potential errors, we can enclose our email sending logic within a try–catch block, catching the instances of the MailException class. Below is a code snippet demonstrating how to handle MailException using a try-catch block:

try {
    // ...
    mailer.sendMail(email);
} catch (MailException e) {
    // ...
}

Moreover, validating email addresses before dispatching them can mitigate the likelihood of errors during the email transmission process. We can achieve this by using the validate() method provided by the mailer object:

boolean validEmailAdd = mailer.validate(email);
if (validEmailAdd) {
    mailer.sendMail(email);
} else {
    // prompt user invalid email address
}

8. Advanced Configuration Options

Additionally, Simple Java Mail offers various configuration options beyond the basic functionalities. Let’s explore additional configuration options available, such as setting custom headers, configuring delivery or reading receipts, and limiting email size.

8.1. Setting Custom Headers

We can define custom headers for the emails using the withHeader() method on the MailerBuilder class. This allows us to include additional information beyond the standard headers:

Email email = Email.Builder
  .from("sender@example.com")
  .to("recipient@example.com")
  .withSubject("Email with Custom Header")
  .withPlainText("This is an important message.")
  .withHeader("X-Priority", "1")
  .buildEmail();

8.2. Configure Delivery/Read Receipt

A delivery receipt confirms that an email has been delivered to the recipient’s mailbox, while a read receipt confirms that the recipient has opened or read the email. Simple Java Mail provides built-in support for configuring these receipts using specific email headers: Return-Receipt-To for delivery receipts and Disposition-Notification-To for reading receipts.

We can explicitly define the email address to which the receipts should be sent. If we don’t provide an address, it’ll default to using the replyTo address if it’s available, or it uses the fromAddress.

Here’s how we can configure these receipts:

Email email = EmailBuilder.startingBlank()
  .from("sender@example.com")
  .to("recipient@example.com")
  .withSubject("Email with Delivery/Read Receipt Configured!")
  .withPlainText("This is an email sending with delivery/read receipt.")
  .withDispositionNotificationTo(new Recipient("name", "address@domain.com", Message.RecipientType.TO))
  .withReturnReceiptTo(new Recipient("name", "address@domain.com", Message.RecipientType.TO))
  .buildEmail();

8.3. Limit Maximum Email Size

Many email servers have restrictions on the maximum size of emails they can accept. Simple Java Mail provides a feature to help us prevent sending emails that exceed these limitations. This can save us from encountering errors during email delivery attempts.

We can configure the maximum allowed email size using the withMaximumEmailSize() method on the MailerBuilder object. This method takes an integer value representing the size limit in bytes:

Mailer mailer = MailerBuilder
  .withMaximumEmailSize(1024 * 1024 * 5)
  .buildMailer();

In this example, the maximum email size is set to 5 Megabytes. If we attempt to send an email that surpasses the defined limit, Simple Java Mail throws a MailerException with a cause of EmailTooBigException.

9. Conclusion

In this article, we’ve explored various aspects of Simple Java Mail, including sending emails with attachments and HTML content with embedded images. Additionally, we dove into its advanced functionalities, such as managing delivery, read receipts, and handling email replies and forwards.

Overall, it’s best suited for Java applications that require sending emails straightforwardly and efficiently.

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

       

1. Overview

When using Spring Data JPA we may encounter issues during the bootstrap time. Some of the beans may not be created, causing the application not to start. While the actual stack trace may vary, generally, it looks like this:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'requestMappingHandlerAdapter'
...
Caused by: java.lang.IllegalArgumentException: Not a managed type: ...OurEntity
	at org.hibernate.metamodel.internal.MetamodelImpl.managedType(MetamodelImpl.java:583)
	at org.hibernate.metamodel.internal.MetamodelImpl.managedType(MetamodelImpl.java:85)
...

The root cause is a “Not a managed type” exception. In this article, we’ll delve into the possible reasons for this exception and explore its solutions.

2. Missed @Entity Annotation

One possible reason for facing this exception is that we may forget to mark our entity using the @Entity annotation.

2.1. Reproducing the Issue

Let’s assume we have the following entity class:

public class EntityWithoutAnnotation {
    @Id
    private Long id;
}

We also have its Spring Data JPA repository:

public interface EntityWithoutAnnotationRepository
  extends JpaRepository<EntityWithoutAnnotation, Long> {
}

And finally, we have the application class that scans all the classes mentioned above:

@SpringBootApplication
public class EntityWithoutAnnotationApplication {
}

Let’s try to bootstrap the Spring context using this application:

@Test
void givenEntityWithoutAnnotationApplication_whenBootstrap_thenExpectedExceptionThrown() {
    Exception exception = assertThrows(Exception.class,
      () -> SpringApplication.run(EntityWithoutAnnotationApplication.class));
    assertThat(exception)
      .getRootCause()
      .hasMessageContaining("Not a managed type");
}

As expected, we encountered the “Not a managed type” exception related to our entity.

2.2. Fixing the Issue

Let’s add the @Entity annotation to the fixed version of our entity:

@Entity
public class EntityWithoutAnnotationFixed {
    @Id
    private Long id;
}

The application and repository classes remain the same. Let’s try to bootstrap the application again:

@Test
void givenEntityWithoutAnnotationApplicationFixed_whenBootstrap_thenRepositoryBeanShouldBePresentInContext() {
    ConfigurableApplicationContext context = run(EntityWithoutAnnotationFixedApplication.class);
    EntityWithoutAnnotationFixedRepository repository = context
      .getBean(EntityWithoutAnnotationFixedRepository.class);
    assertThat(repository).isNotNull();
}

We successfully retrieved the ConfigurableApplicationContext instance and obtained the repository instance from there.

3. Migration From javax.persistance to jakarta.persistance

We may face another case of this exception when migrating our application to Jakarta persistence API.

3.1. Reproducing the Issue

Let’s assume we have the next entity:

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
@Entity
public class EntityWithJakartaAnnotation {
    @Id
    private Long id;
}

Here we started using the jakarta.persistence package, but we’re still using Spring Boot 2. We’ll create the repository and application classes similarly to how we created them in the previous section.

Now, let’s try to bootstrap the application:

@Test
void givenEntityWithJakartaAnnotationApplication_whenBootstrap_thenExpectedExceptionThrown() {
    Exception exception = assertThrows(Exception.class,
      () -> run(EntityWithJakartaAnnotationApplication.class));
    assertThat(exception)
      .getRootCause()
      .hasMessageContaining("Not a managed type");
}

We face the “Not a managed type” again. Our JPA entities scanner expects us to use javax.persistence.Entity annotation instead of jakarta.persistence.Entity.

3.2. Fixing the Issue

In this case, we have two potential solutions. We can migrate to Spring Boot 3 and Spring Data JPA starts using jakarta.persistence. Alternatively, we can continue using javax.persistence.Entity if we’re not ready for migration.

4. Missed or Misconfigured @EntityScan

Another common situation where we may encounter the “Not a managed type” exception is when our JPA entity scanner can’t find the entity in the expected path.

4.1. Reproducing the Issue

First, we create another entity:

package com.baeldung.spring.entity;
@Entity
public class CorrectEntity {
    @Id
    private Long id;
}

It has the @Entity annotation and is placed in the entity package. Now, let’s create a repository:

package com.baeldung.spring.repository;
public interface CorrectEntityRepository extends JpaRepository<CorrectEntity, Long> {
}

Our repository is placed in the repository package. Finally, we create an application class:

package com.baeldung.spring.app;
@SpringBootApplication
@EnableJpaRepositories(basePackages = "com.baeldung.spring.repository")
public class WrongEntityScanApplication {
}

It’s placed in the app package. By default, Spring Data looks at repositories under the main class package and its sub-packages. Because of that, we need to specify the base repository package using @EnableJpaRepositories.  Now, let’s try to bootstrap the application:

@Test
void givenWrongEntityScanApplication_whenBootstrap_thenExpectedExceptionThrown() {
    Exception exception = assertThrows(Exception.class,
      () -> run(WrongEntityScanApplication.class));
    assertThat(exception)
      .getRootCause()
      .hasMessageContaining("Not a managed type");
}

We face the “Not a managed type” exception again. The reason is that the logic for entity scan is the same as for repository scan. The packages under our app package were scanned, we didn’t find any entities there and got the exception during the CorrectEntityRepository construction.

4.2. Fixing the Issue

To fix the issue, we can use the @EntityScan annotation.

Let’s create another application class:

@SpringBootApplication
@EnableJpaRepositories(basePackages =
  "com.baeldung.spring.repository")
@EntityScan("com.baeldung.spring.entity")
public class WrongEntityScanFixedApplication {
}

Now we specify the repository package using the @EnableJpaRepositories annotation and the entity package using the @EntityScan annotation. Let’s see how it works:

@Test
void givenWrongEntityScanApplicationFixed_whenBootstrap_thenRepositoryBeanShouldBePresentInContext() {
    ConfigurableApplicationContext context = run(WrongEntityScanFixedApplication.class);
    CorrectEntityRepository repository = context
      .getBean(CorrectEntityRepository.class);
    assertThat(repository).isNotNull();
}

We successfully bootstrapped the application. We retrieved the CorrectEntityRepository from the context, which means it was built and CorrectEntity was successfully recognized as a JPA Entity.

5. Conclusion

In this tutorial, we’ve explored why we might encounter the “Not a managed type” exception when using Spring Data JPA. We’ve also learned solutions to avoid it. The solution choice depends on the particular case, but understanding the possible reasons help us recognize the exact variant we’re facing.

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

       

1. Overview

The GZIP format is a file format used in data compression. The GZipInputStream and GZipOutputStream classes of the Java language implement this file format.

In this tutorial, we’ll learn how to compress data using GZIP in Java. Also, we’ll look at how we can write the compressed data into a byte array.

2. The GZipOutputStream Class

The GZipOutputStream class compresses and writes data to an underlying output stream.

2.1. Object Instantiation

We can use the constructor to create an object of the class:

ByteArrayOutputStream os = new ByteArrayOutputStream();
GZIPOutputStream gzipOs = new GZIPOutputStream(os);

Here, we pass a ByteArrayOutputStream object to the constructor. As a result, we can later get the compressed data in a byte array using the toByteArray() method.

Instead of ByteArrayOutputStream, other instances of OutputStream that we may provide are:

• FileOutputStream: for storing the data in a file
• ServletOutputStream: to transmit the data over the network

In both cases, data is sent to its destination as it comes in.

2.2. Compress Data

The write() method performs data compression:

byte[] buffer = "Sample Text".getBytes();
gzipOs.write(buffer, 0, buffer.length);

The write() method compresses the content of the buffer byte array and writes it to the wrapped output stream.

Besides the buffer byte array, write() includes two more parameters, offset, and length. These define a range of bytes inside the byte array. So, we can use these to specify a range of bytes to write instead of the whole buffer.

Finally, to complete the data compression, we call close():

gzipOs.close();

The close() method writes all the remaining data and closes the stream. So, it’s important to call close(), otherwise we’ll lose data.

3. Getting the Compressed Data in a Byte Array

We’ll create a utility method for data compression using GZIP. We’ll also see how we can get a byte array with the compressed data.

3.1. Compress Data

Let’s create the gzip() method that compresses data in the GZIP format:

private static final int BUFFER_SIZE = 512;
public static void gzip(InputStream is, OutputStream os) throws IOException {
    GZIPOutputStream gzipOs = new GZIPOutputStream(os);
    byte[] buffer = new byte[BUFFER_SIZE];
    int bytesRead = 0;
    while ((bytesRead = is.read(buffer)) > -1) {
        gzipOs.write(buffer, 0, bytesRead);
    }
    gzipOs.close();
}

In the above method, first, we create a new GZIPOutputStream instance. Then, we start copying data from the is input stream, using the buffer byte array.

Notably, we keep reading bytes until we get the -1 return value. The read() method returns -1 when we reach the end of the stream.

3.2. Get a Byte Array With the Compressed Data

Let’s compress a string and write the result into a byte array. We’ll use the gzip() method that we created previously:

String payload = "This is a sample text to test the gzip method. Have a nice day!";
ByteArrayOutputStream os = new ByteArrayOutputStream();
gzip(new ByteArrayInputStream(payload.getBytes()), os);
byte[] compressed = os.toByteArray();

Here, we provide input and output streams to the gzip() method. We wrap the payload value inside a ByteArrayInputStream object. After that, we create an empty ByteArrayOutputStream where gzip() writes the compressed data.

Finally, after we invoke gzip(), we get the compressed data using the toByteArray() method.

4. Test

Before testing our code, let’s add the gzip() method in the GZip class. Now, we’re ready to test our code with a unit test:

@Test
void whenCompressingUsingGZip_thenGetCompressedByteArray() throws IOException {
    String payload = "This is a sample text to test method gzip. The gzip algorithm will compress this string. "
        + "The result will be smaller than this string.";
    ByteArrayOutputStream os = new ByteArrayOutputStream();
    GZip.gzip(new ByteArrayInputStream(payload.getBytes()), os);
    byte[] compressed = os.toByteArray();
    assertTrue(payload.getBytes().length > compressed.length);
    assertEquals("1f", Integer.toHexString(compressed[0] & 0xFF));
    assertEquals("8b", Integer.toHexString(compressed[1] & 0xFF));
}

In this test, we compress a string value. We convert the string into a ByteArrayInputStream and supply it to the gzip() method. Also, the output data is written to a ByteArrayOutputStream.

Furthermore, the test is successful if two conditions are true:

1. the compressed data is smaller in size than the uncompressed
2. the compressed byte array starts with the 1f 8b value.

Regarding the second condition, a GZIP file starts with the fixed value 1f 8b to comply with the GZIP file format.

As a result, if we run the unit test we’ll verify that both conditions are true.

5. Conclusion

In this article, we learned how to get the compressed data in a byte array when we use the GZIP file format in the Java language. To do so, we created a utility method for compression. Finally, we tested our code.

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

       

1. Introduction

In application development, the need to perform an update-or-insert operation, also known as “upsert”, is quite common. This operation involves putting a new record into a database table if it doesn’t exist or updating an existing record if it does.

In this tutorial, we’ll learn different approaches to performing update-or-insert operations using Spring Data JPA.

2. Setup

For demo purposes, we’ll use a CreditCard entity:

@Entity
@Table(name="credit_card")
public class CreditCard {
    @Id
    @GeneratedValue(strategy= GenerationType.SEQUENCE, generator = "credit_card_id_seq")
    @SequenceGenerator(name = "credit_card_id_seq", sequenceName = "credit_card_id_seq", allocationSize = 1)
    private Long id;
    private String cardNumber;
    private String expiryDate;
    private Long customerId;
   // getters and setters
}

3. Implementation

We’ll implement update-or-insert using three different approaches.

3.1. Using Repository Method

In this approach, we’ll write a transactional default method in the repository using the save(entity) method, which is inherited from the CrudRepository interface. The save(entity) method inserts the record if it’s new, or it updates the existing entity based on id:

public interface CreditCardRepository extends JpaRepository<CreditCard,Long> {
    @Transactional
    default CreditCard updateOrInsert(CreditCard entity) {
        return save(entity);
    }
}

We’re passing creditCard to the updateOrInsertUsingReposiotry() method inside the CreditCardLogic class, which either inserts or updates the entity based on entity id :

@Service
public class CreditCardLogic {
    @Autowired
    private CreditCardRepository creditCardRepository;
   
    public void updateOrInsertUsingRepository(CreditCard creditCard) {
        creditCardRepository.updateOrInsert(creditCard);
    }
}

One important note for this approach is that whether the entity is to be updated or not is decided by id. If we need to find existing records based on another column, such as cardNumber instead of id, then this approach won’t work. In that case, we can use the approaches that we discussed in later sections.

We can write unit tests to verify our logic. First, let’s save some test data into the credit_card table:

private CreditCard createAndReturnCreditCards() {
    CreditCard card = new CreditCard();
    card.setCardNumber("3494323432112222");
    card.setExpiryDate("2024-06-21");
    card.setCustomerId(10L);
    return creditCardRepository.save(card);
}

We’ll use the above-saved CreditCard for the update. Let’s build a CreditCard object for insert:

private CreditCard buildCreditCard() {
    CreditCard card = new CreditCard();
    card.setCardNumber("9994323432112222");
    card.setExpiryDate("2024-06-21");
    card.setCustomerId(10L);
    return card;
}

We’re ready to write our unit test:

@Test
void givenCreditCards_whenUpdateOrInsertUsingRepositoryExecuted_thenUpserted() {
    // insert test
    CreditCard newCreditCard = buildCreditCard();
    CreditCard existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
    assertNull(existingCardByCardNumber);
    creditCardLogic.updateOrInsertUsingRepository(newCreditCard);
    existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
    assertNotNull(existingCardByCardNumber);
    // update test
    CreditCard cardForUpdate = existingCard;
    String beforeExpiryDate = cardForUpdate.getExpiryDate();
    cardForUpdate.setExpiryDate("2029-08-29");
    existingCardByCardNumber = creditCardRepository.findByCardNumber(cardForUpdate.getCardNumber());
    assertNotNull(existingCardByCardNumber);
    creditCardLogic.updateOrInsertUsingRepository(cardForUpdate);
    assertNotEquals("2029-08-29", beforeExpiryDate);
    CreditCard updatedCard = creditCardRepository.findById(cardForUpdate.getId()).get();
    assertEquals("2029-08-29", updatedCard.getExpiryDate());
}

In the above test, we’re asserting both insert and update operations for the updateOrInsertUsingRepository() method.

3.2. Using Custom Logic

In this approach, we write custom logic inside the CreditCardLogic class, which first checks if the given row already exists in the table, and based on the output, it decides to insert or update the record :

public void updateOrInsertUsingCustomLogic(CreditCard creditCard) {
    CreditCard existingCard = creditCardRepository.findByCardNumber(creditCard.getCardNumber());
    if (existingCard != null) {
        existingCard.setExpiryDate(creditCard.getExpiryDate());
        creditCardRepository.save(creditCard);
    } else {
        creditCardRepository.save(creditCard);
    }
}

As per the above logic, if the cardNumber already exists in the database, then we update that existing entity based on the passed CreditCard object. Otherwise, we insert the passed CreditCard as a new entity in the updateOrInsertUsingCustomLogic() method.

We can write unit tests to verify our custom logic:

@Test
void givenCreditCards_whenUpdateOrInsertUsingCustomLogicExecuted_thenUpserted() {
    // insert test
    CreditCard newCreditCard = buildCreditCard();
    CreditCard existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
    assertNull(existingCardByCardNumber);
    creditCardLogic.updateOrInsertUsingCustomLogic(newCreditCard);
    existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
    assertNotNull(existingCardByCardNumber);
    // update test
    CreditCard cardForUpdate = existingCard;
    String beforeExpiryDate = cardForUpdate.getExpiryDate();
    cardForUpdate.setExpiryDate("2029-08-29");
    creditCardLogic.updateOrInsertUsingCustomLogic(cardForUpdate);
    assertNotEquals("2029-08-29", beforeExpiryDate);
    CreditCard updatedCard = creditCardRepository.findById(cardForUpdate.getId()).get();
    assertEquals("2029-08-29", updatedCard.getExpiryDate());
}

3.3. Using Database Built-In Feature

Many databases provide a built-in feature to handle conflict on insert. For example, PostgreSQL provides “ON CONFLICT DO UPDATE” and MySQL provides “ON DUPLICATE KEY”. Using this feature, we can write a follow-up update statement when there is a duplicate key while inserting a record into the database.

An example query would be like this:

String updateOrInsert = """
    INSERT INTO credit_card (card_number, expiry_date, customer_id)
    VALUES( :card_number, :expiry_date, :customer_id )
    ON CONFLICT ( card_number )
    DO UPDATE SET
    card_number = :card_number,
    expiry_date = :expiry_date,
    customer_id = :customer_id
    """;

For testing, we’re using the H2 database, which doesn’t provide an “ON CONFLICT” feature, but instead, we can use a merge query provided by the H2 database. Let’s add the merge  logic inside the CreditCardLogic class:

@Transactional
public void updateOrInsertUsingBuiltInFeature(CreditCard creditCard) {
    Long id = creditCard.getId();
    if (creditCard.getId() == null) {
        BigInteger nextVal = (BigInteger) em.createNativeQuery("SELECT nextval('credit_card_id_seq')").getSingleResult();
        id = nextVal.longValue();
    }
   String upsertQuery = """
       MERGE INTO credit_card (id, card_number, expiry_date, customer_id)
       KEY(card_number)
       VALUES (?, ?, ?, ?)
       """;
    Query query = em.createNativeQuery(upsertQuery);
    query.setParameter(1, id);
    query.setParameter(2, creditCard.getCardNumber());
    query.setParameter(3, creditCard.getExpiryDate());
    query.setParameter(4, creditCard.getCustomerId());
    query.executeUpdate();
}

In the above logic, we execute a merge query using the native query provided by entityManager.

Now, let’s write the unit test to verify the results:

@Test
void givenCreditCards_whenUpdateOrInsertUsingBuiltInFeatureExecuted_thenUpserted() {
    // insert test
    CreditCard newCreditCard = buildCreditCard();
    CreditCard existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
    assertNull(existingCardByCardNumber);
    creditCardLogic.updateOrInsertUsingBuiltInFeature(newCreditCard);
    existingCardByCardNumber = creditCardRepository.findByCardNumber(newCreditCard.getCardNumber());
    assertNotNull(existingCardByCardNumber);
    // update test
    CreditCard cardForUpdate = existingCard;
    String beforeExpiryDate = cardForUpdate.getExpiryDate();
    cardForUpdate.setExpiryDate("2029-08-29");
    creditCardLogic.updateOrInsertUsingBuiltInFeature(cardForUpdate);
    assertNotEquals("2029-08-29", beforeExpiryDate);
    CreditCard updatedCard = creditCardRepository.findById(cardForUpdate.getId()).get();
    assertEquals("2029-08-29", updatedCard.getExpiryDate());
}

4. Conclusion

In this article, we discussed different approaches to performing update or insert operations in Spring Data JPA. We implemented these approaches along with verification using unit tests. While each database does provide some out-of-the-box features for handling upsert, implementing custom logic in Spring Data JPA on top of upsert based on the id column isn’t that complex.

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

       

1. Overview

Manipulating Strings is a fundamental task when we work with Java. We often need to convert other data types into Strings. Two common approaches for accomplishing this are casting to String and using the String.valueOf() method. They might seem similar on the surface, but some differences between the two methods may affect our code’s behavior.

In this quick tutorial, let’s discuss the differences between them.

2. Casting to String and String.valueOf()

First, let’s look at an example. Let’s say we assigned a String value to a variable with the type Object:

Object obj = "Baeldung is awesome!";

If we want to convert obj to a String, we can cast directly:

String castResult = (String) obj;
assertEquals("Baeldung is awesome!", castResult);

Alternatively, we can use the String.valueOf() method offered by the standard library:

String valueOfResult = String.valueOf(obj);
assertEquals("Baeldung is awesome!", valueOfResult);

As we can see, both approaches work as expected.

Although the two approaches may appear similar at first glance, they actually have some notable differences.

Next, let’s delve into them.

3. When Converting Non-String Objects

We just now assigned a String value to an Object variable. Casting to String and String.valueOf() can convert obj to a String instance.

Next, let’s assign some non-string values to Object variables and see if they still work as expected.

First, let’s test direct casting the non-string object to String:

Object obj = 42;
assertThrows(ClassCastException.class, () -> {String castResult = (String) obj;});
 
Object obj2 = List.of("Baeldung", "is", "awesome");
assertThrows(ClassCastException.class, () -> {String castResult = (String) obj2;});

In the example above, we assigned an integer value (42) to obj, while obj2 holds a List of String values. As demonstrated, direct casting to String throws ClassCastException when the object isn’t of type String. This is straightforward to grasp: since String is a final class, casting to String is valid only if we know the object is a String or null.

Next, let’s see if the String.valueOf() method throws the same exception:

String valueOfResult = String.valueOf(obj);
assertEquals("42", valueOfResult);
 
valueOfResult = String.valueOf(obj2);
assertEquals("[Baeldung, is, awesome]", valueOfResult);

As we can see, when we pass obj and obj2 to String.valueOf(), it doesn’t throw any exception. Instead, it converts non-string objects to String values.

Next, let’s look at String.valueOf()‘s implementation to figure out why this happened:

public static String valueOf(Object obj) {
    return (obj == null) ? "null" : obj.toString();
}

The implementation is indeed straightforward. The String.valueOf() method invokes the toString() method of the input obj. Consequently, it always returns a String, regardless of whether obj is of type String or not.

Moreover, as evident from the implementation of String.valueOf(), the method includes a null-check. So next, let’s examine how direct casting and String.valueOf() handle null values.

4. Handling null Values

Let’s first try to cast a null object to String:

Object obj = null;
String castResult = (String) obj;
assertNull(castResult);

As the example shows, we get a null value by casting a null value to String.

Since we’ve seen the implementation of the String.valueOf() method, the test result won’t be surprising:

String valueOfResult = String.valueOf(obj);
assertNotNull(valueOfResult);
assertEquals("null", valueOfResult);

Unlike direct casting, String.valueOf() never returns null. We get the String “null” if we pass a null value to String.valueOf().

5. Conclusion

Both casting to String and using String.valueOf() can convert non-string data types to String values in Java. In this article, we explored the differences between them.

Next, let’s briefly summarize their key differences:

• Type Flexibility – String.valueOf() accepts inputs of any type and returns their String representations without raising exceptions. Casting, on the other hand, is limited to String values that are referenced by String or a supertype, such as CharSequence, Object, etc, leading to ClassCastException when used incorrectly.
• null Handling – String.valueOf() gracefully handles null values, converting them to the string “null.” Casting to String returns null if the object being cast is null.
• Readability – String.valueOf() is more explicit in its purpose, making the code easier to understand. However, casting to a String might be less clear and can be misinterpreted as an attempt to typecast rather than a conversion to a String.

Therefore, the String.valueOf() method provides a more robust solution for converting different data types to Strings.

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

       

1. Introduction

In our journey through software development, we often encounter scenarios where creating objects with numerous properties becomes intimidating. Cluttering our constructors is making our code less readable. This is precisely where the Builder Pattern shines. The Builder Pattern is a creational design pattern that separates the construction of complex objects from their representation, offering a cleaner and more flexible approach to object creation.

2. Advantages of Builder Pattern

Before we dive into coding, let’s quickly recap the advantages of utilizing the Builder Pattern:

• Flexibility – by decoupling the construction process from the actual object representation, the Builder Pattern allows us to create objects with varying configurations without cluttering our codebase with multiple constructors or setters
• Readability – the Builder Pattern provides fluent interfaces, making our code more readable; this enables us and fellow developers to understand the construction process of complex objects at a glance.
• Immutability – builders can enforce immutability by creating immutable objects once the construction is complete; this ensures thread safety and prevents unintended modification.

Now, let’s roll up our sleeves and delve into the code.

3. Classic Builder Pattern

public class Post {
    private final String title;
    private final String text;
    private final String category;
    Post(Builder builder) {
        this.title = builder.title;
        this.text = builder.text;
        this.category = builder.category;
    }
    public String getTitle() {
        return title;
    }
    public String getText() {
        return text;
    }
    public String getCategory() {
        return category;
    }
    public static class Builder {
        private String title;
        private String text;
        private String category;
        public Builder title(String title) {
            this.title = title;
            return this;
        }
        public Builder text(String text) {
            this.text = text;
            return this;
        }
        public Builder category(String category) {
            this.category = category;
            return this;
        }
        public Post build() {
            return new Post(this);
        }
    }
}

Now, we can use the Builder to create a new object:

Post post = new Post.Builder()
  .title("Java Builder Pattern")
  .text("Explaining how to implement the Builder Pattern in Java")
  .category("Programming")
  .build();

4. Generic Builder Pattern

In Java 8, lambda expressions and method references opened up new possibilities, including a more generic form of the Builder Pattern. Our implementation introduces a GenericBuilder class, which can construct various types of objects by leveraging generics:

public class GenericBuilder<T> {
    private final Supplier<T> supplier;
    private GenericBuilder(Supplier<T> supplier) {
        this.supplier = supplier;
    }
    public static <T> GenericBuilder<T> of(Supplier<T> supplier) {
        return new GenericBuilder<>(supplier);
    }
    public <P> GenericBuilder<T> with(BiConsumer<T, P> consumer, P value) {
        return new GenericBuilder<>(() -> {
            T object = supplier.get();
            consumer.accept(object, value);
            return object;
        });
    }
    public T build() {
        return supplier.get();
    }
}

This class follows a fluent interface, starting with the of() method to create the initial object instance. Then, the with() method sets object properties using lambda expressions or method references.

The GenericBuilder offers flexibility and readability, allowing us to construct every object concisely while ensuring type safety. This pattern showcases Java 8’s expressive power and is an elegant solution for complex construction tasks.

However, a big drawback is that this solution is based on class setters. This implies that our attributes can no longer be final as in the previous example, thus losing the immutability offered by the Builder Pattern.

For our next example we’ll create a new GenericPost class consisting of a default no-args constructor, getters, and setters:

public class GenericPost {
    private String title;
    private String text;
    private String category;
    // getters and setters
}

Now, we can use our GenericBuilder to create a GenericPost:

Post post = GenericBuilder.of(GenericPost::new)
  .with(GenericPost::setTitle, "Java Builder Pattern")
  .with(GenericPost::setText, "Explaining how to implement the Builder Pattern in Java")
  .with(GenericPost::setCategory, "Programming")
  .build();

5. Lombok Builder

Lombok is a library that simplifies Java code by automatically generating common methods such as getters, setters, equals, hashCode, and even constructors.

One of the most appreciated features of Lombok is its support for the Builder Pattern. By annotating a class with @Builder, Lombok generates a builder class with fluent methods for setting properties. This annotation eliminates the need for manual builder class implementation, significantly reducing verbosity

To use Lombok, we need to import the dependency from the Maven central repository:

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.32</version>
</dependency>

Now, we can create a new LombokPost class using the @Builder annotation:

@Builder
@Getter
public class LombokPost {
    private String title;
    private String text;
    private String category;
}

We also used @Setter and @Getter annotations to avoid the boilerplate code. We can then use the builder pattern out of the box to create new objects:

LombokPost lombokPost = LombokPost.builder()
  .title("Java Builder Pattern")
  .text("Explaining how to implement the Builder Pattern in Java")
  .category("Programming")
  .build();

6. Conclusion

The Builder Pattern in Java 8 offers streamlined object construction and improved code readability. With variants like Classic, Generic, and Lombok Builder Patterns, we can tailor our approach to our specific needs. By embracing this pattern and leveraging tools like Lombok, we can write cleaner, more efficient code, driving innovation and success in software development.

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

      

Related Stories

• Builder Pattern and Inheritance

 

1. Introduction

Dealing with date and time values is a common task in software development, especially when building applications that involve scheduling, logging, or any time-sensitive operations. In the same context, the OffsetDateTime class in Java provides a robust solution for representing date and time information with an offset from UTC/GMT.

In this tutorial, we’ll explore how to efficiently convert a string representing date and time information into an OffsetDateTime object in Java.

2. Using OffsetDateTime.parse() Method

One of the simplest approaches to converting a string to an OffsetDateTime object is using the OffsetDateTime.parse(CharSequence text) method. This method parses the input string according to the ISO-8601 format and returns an OffsetDateTime object representing the parsed date and time:

String dateTimeString = "2024-04-11T10:15:30+01:00";

@Test
public void givenDateTimeString_whenUsingOffsetDateTimeParse_thenConvertToOffsetDateTime() {
    OffsetDateTime offsetDateTime = OffsetDateTime.parse(dateTimeString);
    OffsetDateTime expected = OffsetDateTime.of(2024, 4, 11, 10, 15, 30, 0, ZoneOffset.ofHours(1));
    assertEquals(expected, offsetDateTime);
}

In this example, the dateTimeString represents a specific date and time formatted according to the ISO-8601 standard. Moreover, we use the OffsetDateTime.parse() method, which interprets the input string dateTimeString and constructs an OffsetDateTime object accordingly.

Furthermore, this parsing process involves extracting the individual components of the date and time from the string and determining the offset from UTC/GMT. The resulting OffsetDateTime object represents the parsed date and time information, including the offset.

3. Using DateTimeFormatter With OffsetDateTime.parse()

Another approach to converting strings to OffsetDateTime objects is by using the DateTimeFormatter class to specify the input string’s format explicitly. Note that this approach provides more flexibility and allows for parsing strings with custom date and time formats.

Here’s the implementation:

@Test
public void givenDateTimeStringAndFormatter_whenUsingDateTimeFormatter_thenConvertToOffsetDateTime() {
    String customDateTimeString = "11-04-2024 10:15:30 +0100";
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd-MM-yyyy HH:mm:ss Z");
    OffsetDateTime offsetDateTime = OffsetDateTime.parse(customDateTimeString, formatter);
    OffsetDateTime expected = OffsetDateTime.of(2024, 4, 11, 10, 15, 30, 0, ZoneOffset.ofHours(1));
    assertEquals(expected, offsetDateTime);
}

Here, we utilize the DateTimeFormatter class to create a custom formatter corresponding to the input string’s format. Additionally, the pattern (dd-MM-yyyy HH:mm:ss Z) specifies the expected structure of the date and time components in the input string, including the offset from UTC/GMT.

Once the formatter is created, we employ it along with the OffsetDateTime.parse() method to parse the customDateTimeString and produce an OffsetDateTime object.

4. Conclusion

In conclusion, converting strings to OffsetDateTime objects is crucial for handling date and time in Java applications.

Whether it’s parsing date-time strings from user input or external data sources, converting them into OffsetDateTime objects allows for seamless manipulation and processing of date and time data.

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

       

 1. Overview

2. EntityManager and EntityManagerFactory

@PersistenceContext
private EntityManager entityManager;

@Entity
@Table(name = "PRODUCT")
public class Product {
    
    @Id
    private Long id;
    private String name;
    private double price;
    // standard constructor, getters, setters
}

@Service
public class PersistenceContextProductService {
    @PersistenceContext(type = PersistenceContextType.TRANSACTION)
    private EntityManager entityManagerTransactionType;
    @PersistenceContext(type = PersistenceContextType.EXTENDED)
    private EntityManager entityManagerExtendedType;
    @Transactional
    void insertProductWithTransactionTypePersistenceContext(Product product) {
        entityManagerTransactionType.persist(product);
    }
    Product findWithTransactionTypePersistenceContext(long id) {
        return entityManagerTransactionType.find(Product.class, id);
    }
    void insertProductWithExtendedTypePersistenceContext(Product product) {
        entityManagerExtendedType.persist(product);
    }
    Product findWithExtendedTypePersistenceContext(long id) {
        return entityManagerExtendedType.find(Product.class, id);
    }
}

@Test
void whenProductPersistWithTransactionPersistenceContext_thenShouldPersist() {
    Product p = new Product(1L, "Product 1", 100.0);
    persistenceContextProductService.insertProductWithTransactionTypePersistenceContext(p);
    Product productFromTransactionScoped = persistenceContextProductService.findWithTransactionTypePersistenceContext(1L);
    Assertions.assertNotNull(productFromTransactionScoped);
    Product productFromExtendedScoped = persistenceContextProductService.findWithExtendedTypePersistenceContext(1L);
    Assertions.assertNotNull(productFromExtendedScoped);
}

@Test
void whenProductPersistWithExtendedPersistence_thenShouldPersist() {
    Product product = new Product(2L, "Product 1", 100.0);
    persistenceContextProductService.insertProductWithExtendedTypePersistenceContext(product);
    Product productFromExtendedScoped = persistenceContextProductService.findWithExtendedTypePersistenceContext(2L);
    Assertions.assertNotNull(productFromExtendedScoped);
    Product productFromTransactionScoped = persistenceContextProductService.findWithTransactionTypePersistenceContext(2L);
    Assertions.assertNull(productFromTransactionScoped);
}

@PersistenceUnit(name = "persistence-unit-name")
private EntityManagerFactory entityManagerFactory;

<persistence-unit name="com.baeldung.contextvsunit.h2_persistence_unit" transaction-type="RESOURCE_LOCAL">
    <description>EntityManager serializable persistence unit</description>
    <class>com.baeldung.contextvsunit.entity.Product</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <properties>
        <property name="hibernate.hbm2ddl.auto" value="update"/>
        <property name="hibernate.show_sql" value="true"/>
        <property name="hibernate.generate_statistics" value="false"/>
        <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
        <property name="jakarta.persistence.jdbc.driver" value="org.h2.Driver"/>
        <property name="jakarta.persistence.jdbc.url" value="jdbc:h2:mem:db2;DB_CLOSE_DELAY=-1"/>
        <property name="jakarta.persistence.jdbc.user" value="sa"/>
        <property name="jakarta.persistence.jdbc.password" value=""/>
    </properties>
</persistence-unit>

@Service
public class PersistenceUnitProductService {
    @PersistenceUnit(name = "com.baeldung.contextvsunit.h2_persistence_unit")
    private EntityManagerFactory emf;
    @Transactional
    void insertProduct(Product product) {
        EntityManager entityManager = emf.createEntityManager();
        entityManager.persist(product);
    }
    Product find(long id) {
        EntityManager entityManager = emf.createEntityManager();
        return entityManager.find(Product.class, id);
    }
}

@Test
void whenProductPersistWithEntityManagerFactory_thenShouldPersist() {
    Product p = new Product(1L, "Product 1", 100.0);
    persistenceUnitProductService.insertProduct(p);
    Product createdProduct = persistenceUnitProductService.find(1L);
    assertNotNull(createdProduct);
}

       

1. Overview

Moving averages are a fundamental tool in analyzing trends and patterns in data and are widely used in finance, economics, and engineering.

They help smooth out short-term fluctuations and reveal underlying trends, making data easier to interpret.

In this tutorial, we’ll explore various methods and techniques for calculating moving averages, ranging from traditional approaches to libraries and Stream API’s.

2. Common Methods for Calculating Moving Averages

In this section, we’ll explore three common methods for calculating moving averages.

2.1. Using Apache Commons Math Library

Apache Commons Math is a powerful Java library that offers a wide range of mathematical and statistical functions, including tools for calculating moving averages.

By utilizing the DescriptiveStatistics class from the Apache Commons Math library, we can streamline the process of moving average computation and leverage optimized algorithms for efficient data processing. It adds data points to the statistics object and retrieves the mean, which represents the moving average.

Let’s use the DescriptiveStatistics class to calculate a moving average with a windowSize:

public class MovingAverageWithApacheCommonsMath {
    private final DescriptiveStatistics stats;
    public MovingAverageWithApacheCommonsMath(int windowSize) {
        this.stats = new DescriptiveStatistics(windowSize);
    }
    public void add(double value) {
        stats.addValue(value);
    }
    public double getMovingAverage() {
        return stats.getMean();
    }
}

Let’s test our implementation:

@Test
public void whenValuesAreAdded_shouldUpdateAverageCorrectly() {
    MovingAverageWithApacheCommonsMath movingAverageCalculator = new MovingAverageWithApacheCommonsMath(3);
    movingAverageCalculator.add(10);
    assertEquals(10.0, movingAverageCalculator.getMovingAverage(), 0.001);
    movingAverageCalculator.add(20);
    assertEquals(15.0, movingAverageCalculator.getMovingAverage(), 0.001);
    movingAverageCalculator.add(30);
    assertEquals(20.0, movingAverageCalculator.getMovingAverage(), 0.001);
}

First, we create an instance of the MovingAverageWithApacheCommonsMath class with a window size of 3. Then, three values (10, 20, and 30) are added to the calculator individually, and its mean is verified.

2.2. Using Circular Buffer Approach

The circular buffer approach is a classic method for calculating moving averages and is known for its efficient memory usage. This approach is straightforward and may offer better performance in some cases, especially if we’re concerned about the overhead of external dependencies.

In this approach, new data points overwrite the oldest ones, and the average is calculated based on the current elements in the buffer.

By cycling through the buffer circularly, we can achieve a constant time complexity for each update, making it suitable for real-time data processing applications.

Let’s calculate the moving average using a circular buffer:

public class MovingAverageByCircularBuffer {
    private final double[] buffer;
    private int head;
    private int count;
    public MovingAverageByCircularBuffer(int windowSize) {
        this.buffer = new double[windowSize];
    }
    public void add(double value) {
        buffer[head] = value;
        head = (head + 1) % buffer.length;
        if (count < buffer.length) {
            count++;
        }
    }
    public double getMovingAverage() {
        if (count == 0) {
            return Double.NaN;
        }
        double sum = 0;
        for (int i = 0; i < count; i++) {
            sum += buffer[i];
        }
        return sum / count;
    }
}

Let’s write a test case to verify the method:

@Test
public void whenValuesAreAdded_shouldUpdateAverageCorrectly() {
    MovingAverageByCircularBuffer ma = new MovingAverageByCircularBuffer(3);
    ma.add(10);
    assertEquals(10.0, ma.getMovingAverage(), 0.001);
    ma.add(20);
    assertEquals(15.0, ma.getMovingAverage(), 0.001);
    ma.add(30);
    assertEquals(20.0, ma.getMovingAverage(), 0.001);
}

We create an instance of the MovingAverageByCircularBuffer class with a window size of 3. After adding each value, the test asserts that the calculated moving average matches the expected value with a tolerance of 0.001.

2.3. Using Exponential Moving Average

Another approach is to use exponential smoothing to calculate the moving average.

Exponential smoothing assigns exponentially decreasing weights to older observations, which can be useful for capturing trends and reacting quickly to changes in the data:

public class ExponentialMovingAverage {
    private double alpha;
    private Double previousEMA;
    public ExponentialMovingAverage(double alpha) {
        if (alpha <= 0 || alpha > 1) {
            throw new IllegalArgumentException("Alpha must be in the range (0, 1]");
        }
        this.alpha = alpha;
        this.previousEMA = null;
    }
    public double calculateEMA(double newValue) {
        if (previousEMA == null) {
            previousEMA = newValue;
        } else {
            previousEMA = alpha * newValue + (1 - alpha) * previousEMA;
        }
        return previousEMA;
    }
}

Here, the alpha parameter controls the rate of decay, with smaller values giving more weight to recent observations.

Exponential moving averages are particularly useful when we want to react quickly to changes in the data while still capturing longer-term trends.

Let’s verify it with a test case:

@Test
public void whenValuesAreAdded_shouldUpdateExponentialMovingAverageCorrectly() {
    ExponentialMovingAverage ema = new ExponentialMovingAverage(0.4);
    assertEquals(10.0, ema.calculateEMA(10.0), 0.001);
    assertEquals(14.0, ema.calculateEMA(20.0), 0.001);
    assertEquals(20.4, ema.calculateEMA(30.0), 0.001);
}

We first create an instance of ExponentialMovingAverage (EMA) with a smoothing factor (alpha) of 0.4.

Then, as each value is added, the test asserts that the calculated EMA matches the expected value within a small tolerance of 0.001.

2.4. Stream-Based Approach

We can leverage the Stream API to calculate moving averages in a more functional and declarative manner. This approach is particularly useful if we want to deal with data streams or collections.

Here’s a simplified example of how we can use a stream-based approach to calculate a moving average:

public class MovingAverageWithStreamBasedApproach {
    private int windowSize;
    public MovingAverageWithStreamBasedApproach(int windowSize) {
        this.windowSize = windowSize;
    }
    public double calculateAverage(double[] data) {
        return DoubleStream.of(data)
                .skip(Math.max(0, data.length - windowSize))
                .limit(Math.min(data.length, windowSize))
                .summaryStatistics()
                .getAverage();
    }
}

Here , we created a stream from the input data array, skipping elements outside the specified window size, limiting the stream to the windowSize, and then using summaryStatistics() to calculate the average.

This approach leverages the functional programming capabilities of Java Streams API to perform the calculation in a concise and efficient manner.

Now, let’s write some JUnit tests to make sure our code works as expected:

@Test
public void whenValidDataIsPassed_shouldReturnCorrectAverage() {
    double[] data = {10, 20, 30, 40, 50};
    int windowSize = 3;
    double expectedAverage = 40;
    MovingAverageWithStreamBasedApproach calculator = new MovingAverageWithStreamBasedApproach(windowSize);
    double actualAverage = calculator.calculateAverage(data);
    assertEquals(expectedAverage, actualAverage);
}

In these tests, we check if our calculateAverage() method returns the correct average for given scenarios such as valid data and windowSize.

3. Additional Methods

While the above methods are some of the more convenient and efficient ways to calculate moving averages in Java, there are alternative approaches we can consider depending on our specific requirements and constraints. Here, we’ll introduce two such approaches.

3.1. Parallel Processing

If performance is our top priority and we have access to multiple CPU cores, we can utilize parallel processing techniques to compute moving averages more efficiently.

Java provides support for parallel streams, which can automatically distribute computation across multiple threads.

3.2. Weighted Moving Average

The Weighted Moving Average (WMA) is a method for calculating moving averages that assigns different weights to each data point within the window.

The weights are typically determined based on predefined criteria such as significance, relevance, or proximity to the center of the window.

3.3. Cumulative Moving Average

The Cumulative Moving Average (CMA) calculates the average of all data points up to a certain point in time. Unlike other moving average methods, CMA does not use a fixed-size window but includes all available data.

4. Conclusion

Calculating moving averages is a fundamental aspect of time-series analysis, with applications spanning various domains such as finance, economics, and engineering.

Using Apache Commons Math, circular buffer, and exponential moving average techniques, analysts can gain valuable insights into their data’s underlying trends and patterns.

Moreover, exploring weighted and cumulative moving averages expands the analyst’s toolkit, enabling more sophisticated analysis and interpretation of time-series data.

Again, the choice depends entirely on specific project requirements and preferences.

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

       

1. Spring and Java

>> A preview of Jakarta Data 1.0 (Part II) [in.relation.to]

Another new persistence specification for Java: exploring some dynamic features of Jakarta Data like static metamodel and its applications. Interesting.

>> Spring AI – Multimodality – Orbis Sensualium Pictus [spring.io]

Going beyond learning from just one single source of data: meet multimodal LLMs and take advantage of it in Spring AI.

Also worth reading:

• >> It’s long past time to stop using Date [in.relation.to]
• >> Revolutionizing time tracking: how Quarkus transformed our backend development [quarkus.io]
• >> Hibernate ORM 6.5 – Arbitrary generated values retrieval [in.relation.to]
• >> JEP 469: Vector API (Eighth Incubator) [openjdk.org]
• >> Debugging Using JMX Revisited [foojay.io]
• >> What’s New in JMC 9? – Sip of Java [inside.java]
• >> JDK Mission Control 9.0.0 Requires JDK 17 [infoq.com]
• >> Writing Integration Tests for Spring Boot Web Applications: Spring Profiles [petrikainulainen.net]
• >> Jextract Guide [openjdk.org]
• >> Debug Without Breakpoints [foojay.io]
• >> JDK 17 approaches end-of-permissive license [oracle.com]

Webinars and presentations:

• >> Spring Tips: GRPC [spring.io]
• >> A Bootiful Podcast: Spring founders Rod Johnson and Juergen Hoeller on the 20th Anniversary of Spring Framework 1.0 [spring.io]
• >> Java Withers – Inside Java Newscast #67 [inside.java]
• >> Uploading Files With Quarkus (Update) [sebastian-daschner.com]

Time to upgrade:

• >> JDK 22.0.1, 21.0.3, 17.0.11, 11.0.23, and 8u411 Have Been Released! [oracle.com]
• >> Spring Framework 6.2.0-M1: Overriding Beans in Tests [spring.io]
• >> Spring Boot 3.1.11, 3.2.5, and 3.3.0-RC1 available now [spring.io]
• >> Spring Security 5.8.12, 6.1.9, and 6.2.4 are available now [spring.io]
• >> Hibernate 7.0.0.Alpha1 [in.relation.to]
• >> Quarkus 3.8.4, 3.9.4, and 3.2.12.Final released [quarkus.io]
• >> Spring for Apache Kafka 3.0.16, 3.1.4 and 3.2.0-RC1 Available Now [spring.io]
• >> Spring Authorization Server 1.3.0-RC1, 1.2.4 and 1.1.7 available now [spring.io]
• >> Spring Modulith 1.2 RC1 released [spring.io]
• >> JReleaser becomes 3 [andresalmiray.com]

2. Technical & Musings

>> Is Agile always the answer? [blog.scottlogic.com]

Is Agile a silver bullet? can we use it everywhere? An interesting take on Agile and when it’s most useful.

Also worth reading:

• >> Async APIs – don’t confuse your events, commands and state [blog.scottlogic.com]
• >> The Alternative Implementation Problem [pointersgonewild.com]
• >> Forecast Costs Responsibly [jbrains.ca]

3. Pick of the Week

>> From the 80’s to 2024 – how CI tests were invented and optimized [graphite.dev]

       

1. Introduction

In various text processing tasks, it’s common to encounter scenarios where we need to find the nth last occurrence of a specific character within a given string. Moreover, this operation can be particularly useful in tasks such as parsing logs, analyzing textual data, or extracting relevant information from strings.

In this tutorial, we’ll explore various techniques to find the nth last occurrence of a character in a string using Java.

2. Using Traditional Looping

One conventional approach to finding the nth last occurrence of a character in a string is through iterative looping. In this approach, we iterate through the string from the end, counting occurrences of the target character until we reach the desired position.

Let’s see how this can be implemented:

String str = "Welcome to Baeldung";
char target = 'e';
int n = 2;
int expectedIndex = 6;
@Test
public void givenStringAndCharAndN_whenFindingNthLastOccurrence_thenCorrectIndexReturned() {
    int count = 0;
    int index = -1;
    for (int i = str.length() - 1; i >= 0; i--) {
        if (str.charAt(i) == target) {
            count++;
            if (count == n) {
                index = i;
                break;
            }
        }
    }
    assertEquals(expectedIndex, index);
}

In this test method, we systematically iterate over the characters of the string str in reverse order. So, we create variables such as count to track occurrences and index to store the index of the desired occurrence, and we meticulously manage the search process.

Moreover, each character is inspected to determine if it matches the target character, incrementing the count variable accordingly until the desired nth occurrence is reached.

Finally, we validate that the obtained index corresponds accurately to the expectedIndex, ensuring the correctness of our implementation.

3. Using Java Streams and IntStream

Another approach involves using Java streams and the IntStream class to manipulate character indices in the string. Here’s an example:

@Test
public void givenStringAndCharAndN_whenFindingNthLastOccurrenceUsingStreams_thenCorrectIndexReturned() {
    OptionalInt result = IntStream.range(0, str.length())
      .map(i -> str.length() - 1 - i)
      .filter(i -> str.charAt(i) == target)
      .skip(n - 1)
      .findFirst();
    int index = result.orElse(-1);
    assertEquals(expectedIndex, index);
}

In this test method, we adopt a functional programming approach, leveraging the IntStream.range() method to generate a stream of integer indices representing the characters of the input string. Then, we map each index to its position at the end of the string, facilitating traversal in reverse order.

Subsequently, we apply a filtering operation to retain only those indices where the corresponding character matches the target character. By employing the skip(n-1) method, we bypass the initial occurrences and then use findFirst() to locate the index of the nth last occurrence, encapsulated within an OptionalInt.

Upon obtaining the result, we extract the index from the OptionalInt and validate its accuracy against the expectedIndex.

This functional programming approach not only offers a more expressive and concise solution but also aligns with modern programming paradigms emphasizing immutability and function composition.

4. Conclusion

In this article, we’ve explored different methods to find the nth last occurrence of a character within a string using Java. We’ve covered both traditional looping techniques and functional programming approaches leveraging Java streams.

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

       

1. Overview

Correctly handling numbers is crucial to any programming language. However, some applications rely more on the exact values and require a better representation of decimal numbers.

For example, we should avoid number representations that allow rounding errors and overflows while working with money or precise calculations. For such cases, it’s highly recommended to use the BigDecimal class.

Although BigDecimal provides many benefits, it displays a non-intuitive behavior regarding equals() and compareTo() methods. In this tutorial, we’ll dive into their differences, underlying implementations, and implications for these methods.

2. compareTo()

Let’s start with the easiest of these methods: compareTo(). The beauty of it is that its behavior is expected and would be considered consistent and logical for most developers.

This method compares two numbers and returns an integer value that shows if a number is greater, lesser, or equal to another one. In this context, we refer to the equality of two numbers regarding the compareTo() result being zero. Let’s check the following example of the compareTo() logic:

static Stream<Arguments> decimalCompareToProvider() {
    return Stream.of(
      Arguments.of(new BigDecimal("0.1"), new BigDecimal("0.1"), true),
      Arguments.of(new BigDecimal("1.1"), new BigDecimal("1.1"), true),
      Arguments.of(new BigDecimal("1.10"), new BigDecimal("1.1"), true),
      Arguments.of(new BigDecimal("0.100"), new BigDecimal("0.10000"), true),
      Arguments.of(new BigDecimal("0.10"), new BigDecimal("0.1000"), true),
      Arguments.of(new BigDecimal("0.10"), new BigDecimal("0.1001"), false),
      Arguments.of(new BigDecimal("0.10"), new BigDecimal("0.1010"), false),
      Arguments.of(new BigDecimal("0.2"), new BigDecimal("0.19999999"), false),
      Arguments.of(new BigDecimal("1.0"), new BigDecimal("1.1"), false),
      Arguments.of(new BigDecimal("0.01"), new BigDecimal("0.0099999"), false)
    );
}
@ParameterizedTest
@MethodSource("decimalCompareToProvider")
void givenBigDecimals_WhenCompare_ThenGetReasonableResult(BigDecimal fistDecimal,
  BigDecimal secondDecimal, boolean areComparablySame) {
    assertEquals(fistDecimal.compareTo(secondDecimal) == 0, areComparablySame);
}

The compareTo() method treats the numbers 0.1, 0.10, 0.100, and 0.1000 as the same. It ignores trailing zeros, which is quite reasonable and expected in most cases.

3. compareTo() vs. equals()

While it’s highly recommended to respect the consistency between compareTo() and equals(), it isn’t a strict rule. Here’s the snipped from the documentation of the Comparable interface:

It is strongly recommended (though it isn’t required) that natural orderings be consistent with equals.

The BigDecimal class doesn’t follow this recommendation. The discrepancy between the results of these methods might result in unexpected behavior and hard-to-debug issues.

It’s usual for developers to have issues with this method. The documentation refers to BigDecimal and its unusual behavior in the Comparable interface:

One exception is java.math.BigDecimal, whose natural ordering equates BigDecimal objects with equal numerical values and different representations (such as 4.0 and 4.00). For BigDecimal.equals() to return true, the representation and numerical value of the two BigDecimal objects must be the same.

The BigDecimal documentation also points to the same behavior:

Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale. Therefore, 2.0 is not equal to 2.00 when compared by this method since the former has [BigInteger, scale] components equal to [20, 1] while the latter has components equal to [200, 2].

However, because this information is in the documentation, we can confidently state that no one reads it. Therefore, let’s discuss the behavior of the equals() method more.

3. equals()

The main quirk of the equals() method is that it considers the scale while comparing two numbers. This means that from its perspective, 1.0 and 1.00 aren’t equal.

In some specific cases, we want to distinguish numbers by their precision; for example, in physics, we tend to treat numbers with different precisions as different.

However, we have additional reasons for such behavior in the BigDecimal class.

3.1. Scale

First of all, the representations of the numbers aren’t the same. The scale is stored in a separate field and defines the floating point’s position:

public class BigDecimal extends Number implements Comparable<java.math.BigDecimal> {
    //...
    private final int scale;
    //...
}

Thus, technically, the numbers with different scales aren’t equal as they have different values in their fields.

3.2. hashCode()

Another exciting aspect is the relationships between the equals() and hashCode(). Considering the numbers that differ only in trailing zeros equal, we should also reflect this in the hashCode() calculation, which would complicate it.

In the current implementation, the scale affects the hash code and is consistent with equals():

@Override
public int hashCode() {
    if (intCompact != INFLATED) {
        long val2 = (intCompact < 0)? -intCompact : intCompact;
        int temp = (int)( ((int)(val2 >>> 32)) * 31  + (val2 & LONG_MASK));
        return 31*((intCompact < 0) ?-temp:temp) + scale;
    } else
        return 31*intVal.hashCode() + scale;
}

The comment for hashCode() explains its behavior:

Two BigDecimal objects that are numerically equal but differ in scale (like 2.0 and 2.00) will generally not have the same hash code.

3.3. Operations

Additionally, the same operations on equal numbers should produce the same results. This might not be true if we work on the number with different scales. Java 17 provides the following example in the documentation:

One example that shows how 2.0 and 2.00 are not substitutable for each other under some arithmetic operations are the two expressions:
new BigDecimal(“2.0” ).divide(BigDecimal.valueOf(3), HALF_UP which evaluates to 0.7 and
new BigDecimal(“2.00”).divide(BigDecimal.valueOf(3), HALF_UP which evaluates to 0.67.

This behavior can be shown better in the example with 4.0 and 4.00:

@ParameterizedTest
@CsvSource({
  "2.0, 2.00",
  "4.0, 4.00"
})
void givenNumbersWithDifferentPrecision_WhenPerformingTheSameOperation_TheResultsAreDifferent(
  String firstNumber, String secondNumber) {
    BigDecimal firstResult = new BigDecimal(firstNumber).divide(BigDecimal.valueOf(3), HALF_UP);
    BigDecimal secondResult = new BigDecimal(secondNumber).divide(BigDecimal.valueOf(3), HALF_UP);
    assertThat(firstResult).isNotEqualTo(secondResult);
}

Dividing 4.0 by three would give 1.3, and dividing 4.00 by three would result in 1.33.

3.4. toString()

As a side note, the toString() representation of the numbers with different precision would produce different results. However, the toString() method isn’t connected to the equals() method, and we should never assume we can use it for comparison.

For example, Sets or other data structures that don’t maintain the order might have different toString() representations despite having the same elements.

While we can understand the reasoning behind such implementation of the equals() method, it’s pretty specific and non-intuitive. This might lead to a problem with assertions, and some Java standard methods and data structures may suffer from it.

4. Additional Things (Bugs) to Consider

Let’s review the implications of this behavior while working with BigDecimal. We should consider the implementation of the equals() method wherever it’s used, explicitly or implicitly.

4.1. distinct()

While working with Stream API, the distinct() method might produce unexpected results as it would compare the numbers based on their equality (meaning the result of the equal method). Let’s check the expected behavior first:

Stream.of("0.0", "0.00", "0.0").map(BigDecimal::new).distinct().toArray()

This code results in the following array:

[ 0.0, 0.00 ]

Let’s sort the stream first before taking the distinct values:

Stream.of("0.0", "0.00", "0.0").map(BigDecimal::new).sorted().distinct().toArray()

Due to the different results from the equals() and compareTo(), we can have different positioning of the elements and distinct assumes that the equal elements are grouped. Thus, we might have an incorrect result:

[ 0.0, 0.00, 0.0 ]

This is a known but non-resolved bug. While it might not be the most common use of the distinct(), without being aware of the implementation, it might result in very subtle bugs in our applications.

4.2. Maps and Sets

The differences in the results for the equals() and compareTo() also affect the HashMaps and HashSets. Let’s take the following BigDecimals values:

static Stream<Arguments> decimalProvider() {
    return Stream.of(Arguments.of(Arrays.asList(
      new BigDecimal("1.1"),
      new BigDecimal("1.10"),
      new BigDecimal("1.100"),
      new BigDecimal("0.10"),
      new BigDecimal("0.100"),
      new BigDecimal("0.1000"),
      new BigDecimal("0.2"),
      new BigDecimal("0.20"),
      new BigDecimal("0.200")),
      Arrays.asList(
        new BigDecimal("1.1"),
        new BigDecimal("0.10"),
        new BigDecimal("0.2"))));
}

The behavior correctly adheres to the outlined logic of the equals method. The result would contain all the numbers from the list because they’re considered to be non-equal:

@ParameterizedTest
@MethodSource("decimalProvider")
void givenListOfDecimals_WhenAddingToHashSet_ThenUsingEquals(List<BigDecimal> decimalList) {
    Set<BigDecimal> decimalSet = new HashSet<>(decimalList);
    assertThat(decimalSet).hasSameElementsAs(decimalList);
}

The additional confusion arises from the fact that sorted Maps and Sets behave differently:

@ParameterizedTest
@MethodSource("decimalProvider")
void givenListOfDecimals_WhenAddingToSortedSet_ThenUsingCompareTo(List<BigDecimal> decimalList,
  List<BigDecimal> expectedDecimalList) {
    Set<BigDecimal> decimalSet = new TreeSet<>(decimalList);
    assertThat(decimalSet).hasSameElementsAs(expectedDecimalList);
}

This happens because they rely on the compareTo() instead of the equals() while checking for the existing elements.

5. Trailing Zeros

The best way to resolve the problem is to create a common representation of a number. Because the main issue arises from the difference in trailing zeros, we can use the stripTrailingZeros() method to resolve it:

@ParameterizedTest
@MethodSource("decimalEqualsProvider")
void givenBigDecimals_WhenCheckEqualityWithoutTrailingZeros_ThenTheSameAsCompareTo(BigDecimal fistDecimal,
  BigDecimal secondDecimal) {
    BigDecimal strippedFirstDecimal = fistDecimal.stripTrailingZeros();
    BigDecimal strippedSecondDecimal = secondDecimal.stripTrailingZeros();
    assertEquals(strippedFirstDecimal.equals(strippedSecondDecimal),
      strippedFirstDecimal.compareTo(strippedSecondDecimal) == 0);
}

While this method requires additional CPU cycles and might affect the performance, it’s a better way to ensure the consistency between the equals() and compareTo().

6. Conclusion

BigDecimal is an important Java class that helps avoid rounding errors and overflow. However, as this article discussed, it might introduce other issues.

We should pay close attention to using BigDecimal instances in data structures that rely on order or equality of elements. The same is true for direct comparison of the numbers.

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

       

1. Introduction

In Java, we can use the hashCode() method to generate a hash code value for an object. This value is typically used for various purposes, such as storing objects in collections like HashMap or HashSet, where efficient retrieval and storage are essential.

Besides, writing unit tests for the hashCode() method ensures that it produces consistent and correct hash codes, which is crucial for properly functioning hash-based data structures.

In this article, we’ll delve into the importance of unit testing for the hashCode() method in Java.

2. Understanding the hashCode() Method

In Java, every object inherits the hashCode() method from the Object class, which generates a unique integer hash code value for the object based on its internal state. Typically, this hash code is computed using the memory address or certain object attributes, aiming to provide a fast and efficient way to identify objects:

public class MyClass {
    private String value;
    public MyClass(String value) {
        this.value = value;
    }
    @Override
    public int hashCode() {
        return value != null ? value.hashCode() : 0;
    }
}

Here, we define a simple MyClass class with a value field. The hashCode() method is overridden to calculate the hash code based on the value of this field.

This implementation ensures that objects with the same value produce the same hash code, a fundamental requirement for hash-based data structures.

3. Testing Consistency

One fundamental requirement for the hashCode() method is consistency. An object’s hash code should remain constant across multiple invocations as long as its state remains unchanged. Here’s an example of how to test for consistency:

@Test
public void givenObject_whenTestingHashCodeConsistency_thenConsistentHashCodeReturned() {
    MyClass obj = new MyClass("value");
    int hashCode1 = obj.hashCode();
    int hashCode2 = obj.hashCode();
    assertEquals(hashCode1, hashCode2);
}

Here, we create an instance of the MyClass object named obj with a specific value. We then retrieve the hash code of obj twice, storing the results in variables hashCode1 and hashCode2.

Finally, we use the assertEquals() method to assert that both hash codes are equal, confirming that the hash code remains consistent across multiple invocations for an object with an unchanged state.

4. Testing Equality

Objects with equal states should produce the same hash code. Therefore, it’s essential to verify that objects with identical states generate identical hash codes. Here’s how we can test for equality:

@Test
public void givenTwoEqualObjects_whenTestingHashCodeEquality_thenEqualHashCodesReturned() {
    MyClass obj1 = new MyClass("value");
    MyClass obj2 = new MyClass("value");
    assertEquals(obj1.hashCode(), obj2.hashCode());
}

This test validates that the hashCode() method produces consistent hash codes for objects with identical states. By confirming the equality of hash codes for equal objects, we ensure that hash-based collections can correctly identify and manage objects with the same state.

5. Testing Distribution

A good hash function should produce hash codes that are evenly distributed across the range of possible values. To test for distribution, we can analyze the distribution of hash codes generated for a large number of objects:

@Test
public void givenMultipleObjects_whenTestingHashCodeDistribution_thenEvenDistributionOfHashCodes() {
    List<MyClass> objects = new ArrayList<>();
    for (int i = 0; i < 1000; i++) {
        objects.add(new MyClass("value" + i));
    }
    Set<Integer> hashCodes = new HashSet<>();
    for (MyClass obj : objects) {
        hashCodes.add(obj.hashCode());
    }
    assertEquals(objects.size(), hashCodes.size(), 10);
}

In this test, we create a list of MyClass objects named objects containing 1000 elements. In addition, each object is initialized with a unique value derived from the iteration index. We then iterate over the list and add the hash codes of each object to a set.

Since a set can’t contain duplicate elements, we expect the size of the set (hashCodes.size()) to be equal to the number of objects (objects.size()). The tolerance value of 10 allows for minor variations in hash code distribution.

By comparing the size of the set to the number of objects, we verify that the hash codes generated for the objects exhibit an even distribution.

6. Conclusion

Unit testing the hashCode() method is essential to ensure its correctness, consistency, and distribution. By following effective testing strategies like testing for consistency, equality, and distribution, we can validate the behavior of the hashCode() method and ensure the reliability of hash-based data structures in Java applications.

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