The Problem with Platform Threads

Traditional Java threads (platform threads) are expensive. Each thread consumes ~2MB of memory upfront and takes milliseconds to create. Operating systems limit the number of threads (often to a few thousand), making it impossible to handle millions of concurrent tasks. For I/O-heavy applications (e.g., web servers, databases), this creates a bottleneck:

• CPU underutilization: A thread blocked on I/O (e.g., waiting for a database response) idles the CPU.

• Complex async code: To scale, developers resort to asynchronous frameworks (e.g., CompletableFuture, reactive streams), which split logic into non-blocking callbacks. While efficient, this leads to complex, hard-to-maintain code.

How Java Handles Blocking Operations with Virtual Threads

When a virtual thread encounter a blocking opertation :

1. Unmount: The JVM unmounts the virtual thread from its carrier platform thread.

2. Yield Control: The virtual thread’s stack is moved to heap memory, freeing the platform thread to execute other tasks.

3. Resume: Once the I/O completes, the virtual thread is rescheduled onto any available platform thread.

But how is the yielding done ?
How can the JVM know that the thread is waiting for a blocking operation ?

One word : Continuation.

With the project Loom, all the java blocking operations are using the Continuation objects. Once a blocking operation is run, the Continuation.yield() is called to unmount the virtual thread, storing its execution stack in heap memory. Once the blocking operation completes, Continuation.run() is called, triggering the retrieving of the saved stack from the heap and remounting the virtual thread onto a platform thread, possibly a different one than before. This ensures the virtual thread resumes exactly from where it was suspended

The following diagram shows how java handles blocking operation (opening a file) with virtual threads

Virtual Threads Best Practices

When to Use Virtual Threads

• Blocking Operations: Ideal for operations involving I/O (network calls, database queries, file operations).

• High Concurrency: Suitable for applications requiring thousands or millions of concurrent threads due to their low resource overhead.

When Not to Use Virtual Threads

• In-Memory Computations: Avoid using virtual threads for purely CPU-bound tasks as they introduce additional overhead compared to platform threads.

• Native or Synchronized Blocks: Use cautiously with native calls or synchronized blocks, as virtual threads may become pinned to a platform thread, potentially reducing performance.

Conclusion

Java virtual threads provide a scalable and efficient approach to concurrency, particularly benefiting applications with numerous blocking operations. By effectively managing the mount, unmount, and remount lifecycle through Continuation objects, Java ensures optimal resource utilization and simpler, maintainable code. Virtual threads significantly enhance efficiency by preventing OS threads from idly waiting on I/O operations, thereby reducing overhead. Additionally, they greatly improve scalability by allowing thousands of virtual threads to be managed simultaneously without performance degradation. This model simplifies coding by enabling developers to write straightforward, synchronous code while the runtime handles concurrency intricacies seamlessly, leading to cleaner and more readable applications.

Hey there! Let's dive into design patterns—specifically, the Strategy Pattern. Once you get the hang of it, you'll start seeing it everywhere. The Strategy Pattern is all about defining a group of algorithms, wrapping each one up, and making them easy to switch around. Sounds fancy, right? But honestly, traditional implementations can feel a bit... cumbersome. There's a lot of boilerplate code and extra classes just to change a behavior.

But here’s the good news: with modern Java and its sweet lambda expressions, we can make the Strategy Pattern lightweight, elegant, and, dare I say, fun to use.

Ready to see how it works? Let’s dive in!

The Problem

Alright, so picture this: you've got a service that calculates discounts. Sounds simple, right? But here's the catch—there are different types of discounts, and each one has its own rules. For instance:

• Seasonal Discounts: Limited-time offers based on seasons or holidays.

• Long-Term Client Discounts: Special rewards for loyal, long-term clients.

• Staff Discounts: Perks for your awesome team members.

• Student Discounts: Discounts for the studious crowd because education deserves a break.

And here's where things get tricky: each discount has its own dedicated method (see code). Now you're staring at four methods, each doing its own thing. Before you know it, you've got a service that's bloated with logic and harder to maintain than you'd like.

import java.util.List;
import java.util.stream.Collectors;

public class DiscountService {

    public List<Item> applySeasonalDiscount(List<Item> items) {
        return items.stream()
                .filter(Item::isDiscountable)
                .map(item -> {
                    double discountPercentage = 0.1;
                    discountPercentage += item.getPrice() > 500 ? 0.05 : 0.0;
                    double discountedPrice = item.getPrice() * (1 - discountPercentage);
                    return item.withPrice(discountedPrice);
                })
                .collect(Collectors.toList());
    }

    // Method to calculate discount for long-term clients
    public List<Item> applyLongTermClientDiscount(List<Item> items) {
        return items.stream()
                .filter(Item::isDiscountable)
                .map(item -> {
                    double discountPercentage = 0.15;
                    discountPercentage += item.getPrice() > 1000 ? 0.10 : 0.0;
                    double discountedPrice = item.getPrice() * (1 - discountPercentage);
                    return item.withPrice(discountedPrice);
                })
                .collect(Collectors.toList());
    }

    public List<Item> applyStaffDiscount(List<Item> items) {
        return items.stream()
                .filter(Item::isDiscountable)
                .map(item -> {
                    double discountPercentage = 0.20; 
                    double discountedPrice = item.getPrice() * (1 - discountPercentage);
                    return item.withPrice(discountedPrice);
                })
                .collect(Collectors.toList());
    }

    public List<Item> applyStudentDiscount(List<Item> items) {
        return items.stream()
                .filter(Item::isDiscountable)
                .map(item -> {
                    double discountPercentage = 0.15;
                    discountPercentage += item.getPrice() < 200 ? 0.05 : 0.0;
                    double discountedPrice = item.getPrice() * (1 - discountPercentage);
                    return item.withPrice(discountedPrice);
                })
                .collect(Collectors.toList());
    }
}

Want to add a new type of discount? Get ready to add yet another method and possibly risk messing with existing ones. Not exactly the cleanest, most flexible approach, huh?

Strategy design pattern

Using the Strategy Pattern is a fantastic way to improve the DiscountService class. It makes the code more flexible and organized. Each discount type can have its own strategy, which keeps the code tidy, easier to maintain, and simple to expand.

Here's how the code might look:

Let's start by defining the strategy interface:

public interface DiscountStrategy {
    double calculateDiscountedPrice(Item item);
}

An example of the strategy implementation :

public class SeasonalDiscountStrategy implements DiscountStrategy {
    private final double DISCOUNT_PERCENTAGE = 0.1;
    private final double EXPENSIVE_ITEM_DISCOUNT_PERCENTAGE = 0.15;
    private final double EXPENSIVE_ITEM_THRESHOLD = 500.0;

    @Override
    public double calculateDiscountedPrice(Item item) {
        double discountPercentage = item.getPrice() > EXPENSIVE_ITEM_THRESHOLD ? 
                                            EXPENSIVE_ITEM_DISCOUNT_PERCENTAGE 
                                            : DISCOUNT_PERCENTAGE;
        return item.getPrice() * (1 - discountPercentage);
    }

}

The new DiscountService :

import java.util.List;
import java.util.stream.Collectors;

public class DiscountService {

    private final DiscountStrategy discountStrategy;

    public DiscountService(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public List<Item> applyDiscount(List<Item> items) {
        return items.stream()
                .filter(Item::isDiscountable)
                .map(item -> item.withPrice(discountStrategy.calculateDiscountedPrice(item)))
                .collect(Collectors.toList());
    }
}

So, here's the scoop—every time you want to add a new "strategy," you need to create a brand-new class. That means setting up a class, implementing the interface, and writing what might be just a few lines of code. If you have four types of discounts, congrats—you've just made four separate classes. And don't forget: each class needs its own file, which can clutter up your project.

But wait, there's more. Need to tweak something? You'll be hopping between multiple files just to find the logic. Even if the logic is small, the amount of boilerplate—like method headers, constructors, and imports—makes it feel like you're doing way more work than necessary. Sure, the Strategy Pattern is awesome for complex, reusable behavior, but when your strategies are simple and focused, all that extra structure can feel like carrying a backpack full of bricks to a picnic. It's sturdy but unnecessarily heavy for the task.

The lightweight approach

Instead of setting up a regular interface, let's go with a functional one. A functional interface is just an interface with a single abstract method.

@FunctionalInterface
public interface DiscountStrategy {
    double calculateDiscountedPrice(double price);
}

In the new DiscountService we pass the DiscountStrategy as a prameter, aka our lambda function.

import java.util.List;
import java.util.stream.Collectors;

public class DiscountService {

    public List<Item> applyDiscount(List<Item> items, DiscountStrategy discountStrategy) {
        return items.stream()
                .filter(Item::isDiscountable)
                .map(item -> item.withPrice(discountStrategy.calculateDiscountedPrice(item.getPrice())))
                .collect(Collectors.toList());
    }
}

Example of usage :

public class Main {
    public static void main(String[] args) {
        List<Item> items = List.of(
            new Item("Laptop", 1200, true),
            new Item("Book", 150, true),
            new Item("TV", 600, false)
        );

        DiscountService discountService = new DiscountService();

        List<Item> seasonalDiscountedItems = discountService.applyDiscount(items, 
                                             price -> price * (1 - price > 500 ? 0.15 : 0.1));
        System.out.println("Seasonal Discounts: " + seasonalDiscountedItems);
    }
}

As you can see, this approach is much more straightforward. The code clearly shows what it's doing, and adding a new discount strategy is easy. You don't need to create a new class; you can simply pass a lambda function with the logic, and the discountService will handle the calculation for you.

Which Approach to Choose?

1. Use the Traditional Strategy Pattern:

   • Go for this if you expect to have complex or reusable discount logic.

   • It's a good fit if each strategy needs extra behavior beyond just calculating discounts.

2. Use Functional Interfaces and Lambdas:

   • Choose this if the strategies are simple and don't need to be reused or have extra behavior.

   • It's great for concise, inline implementations in small-to-medium-sized projects.

Both approaches work well, and your choice should depend on how complex your project is and what it needs.

Conclusion

In conclusion, the Strategy Pattern is a fantastic tool in software design. It gives you flexibility and makes your code easier to maintain by letting you swap out different algorithms. The traditional way of doing this can be a bit clunky with lots of extra code. But, by using Java's lambda expressions and functional interfaces, you can simplify the Strategy Pattern, making it more efficient and easier to handle. This modern method not only cuts down on code complexity but also boosts readability and adaptability, especially for projects with straightforward strategies. Whether you go with the traditional method or the lambda-based approach depends on your project's complexity and needs, but both offer great ways to handle dynamic behavior in your applications.

Not quite!!!

Code coverage tells only part of the story. A test suite can hit 100% coverage and still miss critical bugs if it isn't actually validating the correctness of the code that it executes. This is where mutation testing comes in. It gives a deeper and more meaningful look at the effectiveness of your test suite by answering: Do my tests catch actual defects, or do they just run the code?

What is Mutation Testing?

Mutation testing is a powerful technique designed to evaluate the effectiveness of your test suite. It works by deliberately introducing small, intentional changes, or "mutations," into your source code to simulate common programming errors. These mutations might include:

• Changing a comparison operator (e.g., < to <=).

• Replacing a boolean value (e.g., true to false).

• Modifying arithmetic operations (e.g., + to -).

Once mutated, your test suite is executed against this mutated code. The goal is simple: determine whether your tests can detect these defects. If the tests fail, we say the mutant is killed, indicating that the tests are robust enough to detect this defect. On the other hand if the tests pass despite running on the mutant, we say the mutant survives. A surviving mutant is an indication that there is a gap in the test coverage, the tests are not exhaustive enough to detect this subtle change of logic.

Now, consider a real-world scenario: during a routine refactoring, a developer inadvertently changes a < operator to <=. If your test suite cannot detect this defect, the bug might go unnoticed until it reaches production—where the consequences could range from subtle miscalculations to catastrophic failures. This highlights why robust tests are critical when refactoring.

The traditional metric of 100% code coverage, while helpful, doesn't guarantee your tests are effective. Coverage tools only measure whether your code is executed by tests, not whether your tests validate the correctness of the executed code. Mutation testing addresses this limitation by challenging your tests to prove they can identify meaningful changes in behavior. It's not enough to merely cover your code—your tests must challenge it.

Example: Using PIT for Mutation Testing

Set up

Add the PIT Maven plugin in your pom.xml:

<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>LATEST</version>
</plugin>

Let’s add some code

I created a class InsurancePremiumCalculator.java that calculates the amount of money the premium Insured needs to pay based on his age and type of vehicule.

public class InsurancePremiumCalculator {
    private static final double BASE_PREMIUM = 500.0;
    private static final int MIN_AGE = 16;
    private static final int MAX_AGE = 120;

    public double calculatePremium(int age, String vehicleType) {
        if (age < MIN_AGE || age > MAX_AGE) {
            throw new IllegalArgumentException("Invalid age");
        }

        double premium = BASE_PREMIUM;

        // Age factor
        if (age < 25) {
            premium *= 1.5;
        }

        // Vehicle type factor
        premium *= switch (vehicleType.toLowerCase()) {
            case "sports" -> 1.7;
            case "suv" -> 1.3;
            case "sedan" -> 1.0;
            default -> throw new IllegalArgumentException("Invalid vehicle type");
        };

        return Math.round(premium * 100.0) / 100.0;
    }
}

Now for the test class, InsurancePremiumCalculatorTest.java :

class InsurancePremiumCalculatorTest {

    private InsurancePremiumCalculator calculator;

    @BeforeEach
    void setUp() {
        calculator = new InsurancePremiumCalculator();
    }

    @Test
    void testBasicPremium() {
        assertEquals(500.0, calculator.calculatePremium(30, "sedan"));
    }

    @Test
    void testYoungDriverPremium() {
        assertEquals(750.0, calculator.calculatePremium(20, "sedan"));
    }

    @Test
    void testSportsCarPremium() {
        assertEquals(850.0, calculator.calculatePremium(30, "sports"));
    }

    @Test
    void testCombinedFactors() {
        assertEquals(1275.0, calculator.calculatePremium(22, "sports"));
    }

    @Test
    void testSUV() {
        assertEquals(975.0, calculator.calculatePremium(22, "suv"));
    }

    @Test
    void testInvalidAge() {
        assertThrows(IllegalArgumentException.class, () ->
                calculator.calculatePremium(15, "sedan"));
        assertThrows(IllegalArgumentException.class, () ->
                calculator.calculatePremium(121, "sedan"));
    }

    @Test
    void testInvalidVehicleType() {
        assertThrows(IllegalArgumentException.class, () ->
                calculator.calculatePremium(30, "invalid"));
    }

}

Looks pretty exhaustive right ? If you shouldn’t take my word for it, let’s take a look at the tests coverage.

I have a 100% test coverage, every single line in this method is executed in one of my tests suite. Now let’s generate the mutation tests report and take a look at our PIT report.
We generate PIT report using the following command (assuming you have maven installed locally) :

mvn test-compile org.pitest:pitest-maven:mutationCoverage

You should be able to find the PIT report under
target/pit-reports/yourpackage/index.html
Open it in your favorite browser and you should see something like this:

If you click on the class name, you should find a detailed report on the class code mutations.

It seems like our tests suffers from a boundary mutation gap, which means (check PIT docs for more information on mutations types) changing the < or > with a <= and >= was not detected by our tests. In other words, we have no tests that detects whetherour edge cases are respected or not. We can do that by modifying our test suite, the updated version looks something like this :

 package lo;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class InsurancePremiumCalculatorTest {

    private InsurancePremiumCalculator calculator;

    @BeforeEach
    void setUp() {
        calculator = new InsurancePremiumCalculator();
    }

    @Test
    void testBasicPremium() {
        assertEquals(500.0, calculator.calculatePremium(30, "sedan"));
    }

    @Test
    void testYoungDriverPremium() {
        assertEquals(750.0, calculator.calculatePremium(20, "sedan"));
    }

    @Test
    void testSportsCarPremium() {
        assertEquals(850.0, calculator.calculatePremium(25, "sports")); 
        //changing 30 to 25 to test the edge case
    }

    @Test
    void testCombinedFactors() {
        assertEquals(1275.0, calculator.calculatePremium(22, "sports"));
    }

    @Test
    void testSUV() {
        assertEquals(975.0, calculator.calculatePremium(22, "suv"));
    }

    @Test
    void testInvalidAge() {
        assertThrows(IllegalArgumentException.class, () ->
                calculator.calculatePremium(15, "sedan"));
        assertThrows(IllegalArgumentException.class, () ->
                calculator.calculatePremium(121, "sedan"));
    }

    @Test
    void testMaxAge() {
        assertEquals(650.0, calculator.calculatePremium(120, "suv"));
        //explicitly testing the edge cases
    }

    @Test
    void testMinAge() {
        assertEquals(975.0, calculator.calculatePremium(16, "suv"));
        //explicitly testing the edge cases
    }
    @Test
    void testInvalidVehicleType() {
        assertThrows(IllegalArgumentException.class, () ->
                calculator.calculatePremium(30, "invalid"));
    }

}

We run the command again to generate a new report :

BINGO! Our test strength is now 11/11, making our tests more reliable and better equipped to catch bugs if any changes occur.

Conclusion

Mutation testing is an invaluable tool for enhancing test effectiveness and ensuring code quality. By incorporating PIT into your testing strategy, you can uncover hidden weaknesses in your tests and build more robust applications.

In modern software development, data validation is important for keeping data correct and stopping incorrect input from entering a system. Spring Boot offers different ways to do data validation. However, with Java 14's new records feature, we can use a more design-focused way to handle data validation.

This article will explore how Java records can simplify and streamline the data validation process in Spring Boot. We'll adopt a design-driven mindset where each field that requires validation becomes a separate record. Through this modular approach, data becomes cleaner, validation becomes more maintainable, and the intent behind each DTO (Data Transfer Object) becomes more expressive.

Why Use Records for DTOs in Spring Boot?

1. Immutability by Default

Records in Java are immutable, which means their fields can't be changed once they are set. This makes them perfect for DTOs, as they usually move data between different parts of an application without needing changes. Also, I believe that user data entering the application should be kept as is and never altered!

2. Concise Syntax

With records, the boilerplate code for getters, constructors, equals, hashCode, and toString methods is eliminated. This helps reduce the size of DTO classes and makes them more readable and maintainable.

3. Encapsulation with Compact Constructors

The compact constructor in records allows developers to embed validation logic directly within the record's creation process. This ensures that invalid data is immediately rejected, serving as the first line of defense against faulty input. Since records lack a default constructor, the canonical constructor becomes the sole entry point for creating instances, making it the ideal place to enforce these checks.

4. Aligning with Domain-Driven Design (DDD)

Using records for individual fields that require validation promotes a design-driven approach where each field becomes a self-contained component. This aligns with domain-driven design (DDD) principles by enforcing clear, domain-relevant rules directly where the data is defined.

Creating Records as DTOs in Spring Boot

As mentioned before, we'll treat each field/group of fields that needs validation as its own record. This record will include not just the value but also the rules and limits for that value. We will also make use of the record’s compact constructor to add the validation logic.

Below is a step-by-step example to illustrate how this can be implemented.

Step 1: Defining a Record for Field Validation

Suppose we have a User DTO that contains fields such as username, age, and email. Each of these fields will become a separate record, containing its value and validation logic.

Let’s start by defining a Username record:

public record Username(@JsonProperty("value") String value) {
    public Username {
        if(value.isBlank()){
            throw new IllegalArgumentException("Username should not be empty");
        }
    }
}

Here’s what’s happening:

• Compact Constructor: Adds additional validation to enforce that the username should not be empty nor null.

Similarly, let’s define an Age record:

javaCopy codeimport jakarta.validation.constraints.Min;
import jakarta.validation.constraints.Max;

public record Age(@JsonProperty("value") int value) {
    public Age {
        if (value < 18) {
            throw new IllegalArgumentException("Age must be greater than 18.");
        }
    }
}

In this example:

• Compact Constructor: Throws an exception if the age is outside the specified range.

Let’s add an Email record with a regex-based custom validation inside the compact constructor:

public record Email(@JsonProperty("value") String value) {
    public Email {
        if (!value.matches("^[\\w-\\.]+@([\\w-]+\\.)+[\\w-]{2,4}$")) {
            throw new IllegalArgumentException("Invalid email format.");
        }
    }
}

This Email record ensures that the value conforms to a basic email pattern.

Step 2: Combining Fields into a DTO Record

Now, let’s create a User record that uses these field-specific records:

public record User(Username username, Age age, Email email) {}

This User record serves as the DTO for the entire user object, made up of individual, validated records. The benefit is that each field is validated when created, ensuring only valid data is included in the User record.

Step 3: Using the DTO in Controller Classes

Now that we have a fully validated User DTO, let’s see how it can be used in a Spring Boot controller:

@RestController
public class UserController {

    @PostMapping("/users")
    public String createUser(@RequestBody User user) {
        // User is guaranteed to be valid at this point
        return "User created successfully: " + user.username().value();
    }
}

Here:

• @RequestBody: Automatically maps the incoming JSON payload to the User record, triggering all field validations.

A more business-oriented validation

Let’s make our own Spring validator

Let's say now that the user has another business constraint: the username must be unique. It's clear that we cannot validate this at the record level since the record is a simple class and has no access to the user repository (no, we are not going to get the bean statically from the Spring context and plug it to the record class 🙂).

Below is a step-by-step example to illustrate how this can be implemented.

Step 1: Let’s create the “UniqueUsername” annotation

@Constraint(validatedBy = UniqueUsernameValidator.class)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
public @interface UniqueUsername {
    String message() default "Username already exists";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};
}

Step 2: Let’s create the UniqueUsernameValidator class

Now let’s implement our validator. For this, we are going to be leveraging the Spring validation module (make sure you add it to your dependency manager). To do so, we are going to implement the ConstraintValidator interface.
NB: Each field present in this annotationwill be further discussed and explained in future articles

@Component
public class UniqueUsernameValidator implements ConstraintValidator<UniqueUsername, String> {

    @Autowired
    private UserRepository userRepository;

    @Override
    public boolean isValid(String username, ConstraintValidatorContext context) {
        return !userRepository.existsByUsername(username);
    }
}

Step 3: Update the existing code

Now let’s make use of our newly created validator.

public record Username(@UniqueUsername @JsonProperty("value") String value) {
    public Username {
        if(value.isBlank()){
            throw new IllegalArgumentException("Username should not be empty");
        }
    }
}

public record User(@Valid Username username, Age age, Email email) {}

@RestController
public class UserController {

    @PostMapping("/users")
    public String createUser(@Valid @RequestBody User user) {
        // User will be valid at this point
        return "User created successfully: " + user.username().value();
    }
}

We use @Valid to enable Spring validation on the object. This annotation also applies to nested objects if their fields use Spring validation, as seen with Username.
In summary, our objects can now validate their own state, either independently or by using Spring validation.

Benefits of Design-Driven Validation with Records

1. Modular Design

Each field is represented as a distinct record, encapsulating its value and validation logic. This modular design makes it easier to reuse validation logic across different DTOs.

2. Early Error Detection

Validation occurs immediately when the records are constructed, ensuring that invalid data is caught as early as possible.

3. Cleaner Code

Using records reduces the boilerplate code in your DTOs, resulting in cleaner, more maintainable code. The use of compact constructors further reduces clutter by consolidating validation logic at the point of data creation.

4. Better Alignment with Business Logic

By encapsulating validation logic within records, the intent behind each validation rule becomes clearer. This aligns with the principles of domain-driven design, where the code reflects the business logic and domain rules.

Drawbacks

1. Potential Performance Overhead

Creating a separate record for every individual field introduces more object allocations and might impact performance.

2. Reduced Readability with Deep Nesting

If each field becomes its own record, the overall DTO can become deeply nested and harder to read. (A better way would be to use a static constructor/ builder 😋)

User user = new User(
    new Username("alice"), 
    new Age(25), 
    new Email("alice@example.com")
);

3. Less intuitive json structure

Since each field/group of fields that need validation are record we drift away from the typical json structure to a more nested one.
The usual JSON we send to create a user is something like this :

{
    "username" : "falcon",
    "age" : 25,
    "email" : "falcon@gmail.com"
}

With this new approach, we will need to make some adjustments to the JSON.

{
    "Username": {
        "value": "falcon"
    },
    "Age": {
        "value": 25
    },
    "email": {
        "value": "falcon@gmail.com"
    },
}

Conclusion

Using records as DTOs in Spring Boot provides a design-focused method for data validation, where each field/ group of fields is a self-contained unit with its own validation rules. This not only makes validation simpler but also improves code readability and maintainability. By using the immutability and compact constructors of records, developers can ensure data integrity right from the start.

As software development evolves, using modern language features like records helps us write clearer, more maintainable, and error-resistant code. In a Spring Boot application, using records as DTOs for validation can result in cleaner and more reliable designs that meet both technical and business needs.

The Old Switch Statement

In Java, the switch statement has long been a fundamental control flow structure for conditional branching. Introduced in the earliest versions of Java, it allowed developers to write code that would execute different branches based on the value of a variable, typically an integer, enum, or string in newer versions.

Let’s say we have an int day that represents the days of the week, 1 being Sunday and 7 being Saturday. We wish to print the day based on that int, or throw an exception if the day is invalid.

Using the traditional switch statement, we get something like this :

void printDayFromInt(int day){
String dayName;

switch (day) {
    case 1:
        dayName = "Sunday";
        break;
    case 2:
        dayName = "Monday";
        break;
    case 3:
        dayName = "Tuesday";
        break;
    case 4:
        dayName = "Wednesday";
        break;
    case 5:
        dayName = "Thursday";
        break;
    case 6:
        dayName = "Friday";
        break;
    case 7:
        dayName = "Saturday";
        break;
    default:
        throw new IllegalStateException();
}
System.out.println(dayName);
}

Key Characteristics of the Old Switch:

• Fall-through Behavior: Without a break statement at the end of each case block, the execution would fall through to the next case.

• Limited Return Capability: The switch statement could not directly return a value. This forces us developers to store the results in variables and handle them outside the switch block.

• Type Restrictions: Before Java 7, switch could only operate on primitive types (such as int, char, short), and Java 7 extended this to String. However, handling complex objects was still cumbersome.

• Verbosity: Multiple break statements and duplicated case handling led to more verbose code that was prone to errors, such as missing breaks leading to unwanted fall-through.

2. Introducing the New Switch Expression

The traditional switch statement worked well for basic control flow, but it became clumsy for more complex conditions, particularly in cases where switches needed to return values. To address these limitations, Java 12 introduced switch expressions, which were further enhanced in Java 14 and fully integrated into Java 17.

Switch expressions bring several benefits:

• Conciseness: The -> syntax eliminates the need for break statements.

• Return Values: A switch expression can return a value directly, allowing more compact code.

• Exhaustiveness: Switch expressions are exhaustive, meaning they must handle every possible input, either through individual cases or a default clause.

Here’s how the same example looks using a switch expression:

void printDayFromInt(int day){
String dayName = switch (day) {
    case 1 -> "Sunday";
    case 2 -> "Monday";
    case 3 -> "Tuesday";
    case 4 -> "Wednesday";
    case 5 -> "Thursday";
    case 6 -> "Friday";
    case 7 -> "Saturday";
    default -> "Invalid day";
};
System.out.println(dayName);
}

Key Improvements:

• No Fall-through: The -> syntax inherently avoids fall-through, so no need for explicit break statements.

• Returning Values: Switch expressions can return a value, which simplifies code significantly. In this example, the result is directly assigned to dayName.

• Multiple Labels: Multiple cases can be combined in a single line using a comma separator.

For instance:

String typeOfDay = switch (day) {
    case 1, 7 -> "Weekend";
    default -> "Weekday";
};

3. Pattern Matching in Switch Expressions (Java 17)

One of the most exciting features introduced in Java 17 is pattern matching in switch expressions. This enhancement allows developers to handle different types of objects directly within a switch expression, eliminating the need for extensive instanceof checks and casting.

In earlier versions of Java, checking for object types in a class hierarchy often required nested if-else or switch blocks, which made the code cumbersome and harder to maintain. Pattern matching in switch provides a more elegant solution.

Let’s consider this scenario, I have three types of days, WeekDays where the workHours are 8 and WeekEnds where workHours are 0. Let’s create an interface Days, that has a single method getWorkHours() and let WeekDays and WeekEnds implement that interface.

interface Days {
    int getWorkHours();
}

class WeekDays implements Days {
    @Override
    public int getWorkHours(){
        return 8;
    }
}

class WeekEnds implements Days {
    @Override
    public int getWorkHours(){
        return 0;
    }
}

Now let’s say we want to print whether the Day I have passed as parameter is a weekend or a weekday.

void printDayType(Day day){
    if(day instanceof WeekEnds){
        System.out.println("WeekEnds 💃");
    }else if(day instanceof WeekDays){
        System.out.println("WeekDays 👨‍💻");
    }
}

Now, let’s use pattern matching in the switch expression to handle the different day types, but first we need to help java understand that WeekDays and WeekEnds are the only classes that inherit from the Day class. To do that we use the permits, sealed and final key words. Let’s update our code.

sealed interface Days permits WeekDays, WeekEnds{
    int getWorkHours();
}

final class WeekDays implements Days {
    @Override
    public int getWorkHours(){
        return 8;
    }
}

final class WeekEnds implements Days {
    @Override
    public int getWorkHours(){
        return 0;
    }
}

void printDayType(Day day){
    switch (day) {
        case WeekEnds weekEnds -> System.out.println("WeekEnds 💃");
        case WeekDays weekDays -> System.out.println("WeekDays 👨‍💻");
    };
}

Benefits of Pattern Matching:

• Eliminates Casting: The switch expression automatically binds the matched type to a variable (e.g., WeekEnds weekEnds), avoiding the need for manual casting.

• More Readable Code: By directly handling types within the switch, the code becomes more concise and readable.

• Safe and Exhaustive: Switch expressions with pattern matching enforce exhaustiveness, which means all possible cases must be handled, leading to safer and more reliable code.

4. Code safety first

Switch expressions in Java significantly enhance code safety by enforcing exhaustiveness. Unlike traditional switch statements, where a developer could forget to handle a specific case, switch expressions ensure that all possible cases are covered. If a case is missing, the compiler will flag it, preventing the code from running until the developer addresses the issue. This compile-time safety check helps to eliminate unhandled cases and ensures that the program behaves predictably in all scenarios. By catching potential errors early, switch expressions reduce runtime bugs, making your code more robust and reliable. Additionally, they promote clearer and more maintainable code, as each branch of logic must be deliberately defined. This feature aligns with the general shift in Java towards more functional, concise, and safer code practices, reducing the risk of unintended behavior or crashes caused by unanticipated inputs.

5. Conclusion

The evolution from the old switch statement to the new switch expression, along with pattern matching, is a big step forward for Java. These changes make code shorter and easier to read, while also adding more safety and flexibility, especially when dealing with complex data structures and class hierarchies.

Switch expressions do more than just make code look nicer. They help prevent errors, make code easier to maintain, and simplify things, especially with pattern matching and polymorphism. Java developers using newer versions should adopt these changes to write cleaner and more efficient code.

This article will explore the following:

1. What are equals() and hashCode()?

2. Why are they important?

3. How are they used in Java collections?

4. Best practices for overriding these methods.

5. The role of the @EqualsAndHashCode annotation in Lombok and how it simplifies the process.

By the end, you'll understand how these methods work, how to implement them correctly, and how to use Lombok to make your Java code simpler.

1. What are equals() and hashCode()?

The equals() Method

The equals() method in Java is defined in the Object class, which means that every Java class inherits it. Its purpose is to compare two objects for equality.

The default implementation of equals() checks for reference equality, meaning two objects are considered equal if they reference the same memory address. This is often not the desired behavior, especially when you want to compare the content of objects rather than their memory locations.

Here's the default implementation from the Object class:

public boolean equals(Object obj) {
    return (this == obj);
}

In most cases, you'll want to override this method in your custom classes to compare object states (i.e., their fields).

The hashCode() Method

The hashCode() method also comes from the Object class. It returns an integer value (the "hash code") associated with the object. The purpose of this method is to allow objects to be efficiently stored and retrieved in hash-based collections like HashMap and HashSet.

The general contract of hashCode() is:

• If two objects are equal according to the equals() method, they must have the same hash code.

• However, two objects having the same hash code doesn't necessarily mean they are equal.

The default implementation of hashCode() in the Object class returns a unique integer based on the object's memory address:

public int hashCode();

2. Why Are equals() and hashCode() Important?

These two methods are critical when storing objects in collections like HashMap, HashSet, or any other collection that uses hashing.

Hash-based Collections: How Do They Work?

Hash-based collections, such as HashMap and HashSet, rely on hashCode() and equals() to store and retrieve objects. When an object is added to a hash-based collection, the collection uses the object's hash code to determine the "bucket" where the object should be placed. If another object is added and it has the same hash code, the collection uses equals() to determine whether the two objects are truly equal or if they are distinct entries.

Here’s a breakdown of how this works:

1. Storing an Object: When you store an object in a HashMap or HashSet, the collection computes the hash code of the object (via the hashCode() method). It then uses this value to determine the bucket in which to place the object.

2. Retrieving an Object: When you search for an object, the collection computes the hash code of the object you're looking for and checks the appropriate bucket. If multiple objects have the same hash code, it uses equals() to differentiate between them.

Common Issues

If equals() and hashCode() are not implemented correctly, you may encounter several issues:

• Duplicate Entries: Objects that are logically equal may be considered different, resulting in duplicates in collections like HashSet.

• Retrieval Issues: If the hash code is not consistent with equals(), objects might not be retrieved correctly from collections.

3. How Are equals() and hashCode() Used in Java Collections?

The Role of equals() and hashCode() in HashSet

A HashSet uses a combination of hashCode() and equals() to ensure that no two equal objects can exist in the set.

• Inserting an Object: When adding an object to the HashSet, the collection computes the object's hash code to determine which bucket to place it in. If another object is already in that bucket, equals() is used to check if the two objects are equal. If they are, the new object is not added.

• Checking for Existence: When checking whether an object exists in a HashSet, the hashCode() of the object is computed to find the right bucket. Then, equals() is used to check if any object in the bucket is equal to the searched object.

The Role of equals() and hashCode() in HashMap

Similarly, HashMap also relies heavily on equals() and hashCode() for managing key-value pairs.

• Inserting a Key-Value Pair: When a key-value pair is inserted, the hash code of the key is computed, and the key is stored in the corresponding bucket. If another key exists in that bucket, equals() is used to check if the keys are equal. If they are, the value is updated.

• Retrieving a Value: When retrieving a value by key, the hash code of the key is used to find the appropriate bucket, and equals() is used to locate the correct key-value pair.

The Role of equals() and hashCode() in Other Collections

Collections like LinkedHashSet, TreeSet, and ConcurrentHashMap also rely on equals() and hashCode(), but some of them have additional ordering constraints or concurrency mechanisms.

4. Best Practices for Overriding equals() and hashCode()

General Guidelines

When overriding equals() and hashCode(), it’s important to follow certain rules to ensure the integrity of your objects in collections.

1. Consistency Between equals() and hashCode():

   • If two objects are considered equal by equals(), they must have the same hash code.

   • It’s not necessary for two objects with the same hash code to be equal, but it’s a common best practice to minimize the chances of hash code collisions.

2. Symmetry in equals():

   • If x.equals(y) is true, then y.equals(x) must also be true.

3. Reflexivity in equals():

   • An object must always be equal to itself: x.equals(x) should always return true.

4. Transitivity in equals():

   • If x.equals(y) is true and y.equals(z) is true, then x.equals(z) should also be true.

5. Consistent Hash Codes:

   • The hashCode() value should be consistent as long as the object's state remains unchanged.

   • Avoid using mutable fields in equals() and hashCode() calculations, as changes to these fields can break collection behavior.

Implementing equals() and hashCode()

Here’s an example of a simple class Person and how to properly override equals() and hashCode():

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (obj == null || getClass() != obj.getClass()) {
            return false;
        }
        Person person = (Person) obj;
        return age == person.age && name.equals(person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

In this example:

• equals() checks both the name and age of the Person objects.

• hashCode() generates a hash code using Objects.hash(), which ensures that two equal objects will have the same hash code.

Handling Null Fields

When overriding equals() and hashCode(), always be careful with null fields. Using Objects.equals() in equals() and Objects.hash() in hashCode() helps avoid NullPointerException.

5. Simplifying with Lombok’s @EqualsAndHashCode

Lombok is a popular Java library that helps reduce boilerplate code. It automatically generates code for common tasks like getters, setters, equals(), hashCode(), and more through annotations.

Lombok’s @EqualsAndHashCode annotation generates the equals() and hashCode() methods for you, following the best practices mentioned earlier. This is extremely useful for reducing code redundancy, especially in classes where equals() and hashCode() would otherwise be manually implemented.

Here’s how you can use Lombok to simplify the Person class:

import lombok.EqualsAndHashCode;

@EqualsAndHashCode
public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

With @EqualsAndHashCode, Lombok generates the equals() and hashCode() methods based on all fields of the class by default. It automatically ensures that two equal objects have the same hash code, and avoids null issues by internally using Objects.equals() and Objects.hash().

Customizing @EqualsAndHashCode

You can customize which fields are used for the equals() and hashCode() methods by specifying them in the annotation:

import lombok.EqualsAndHashCode;

@EqualsAndHashCode(of = {"name"})
public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

In this example, Lombok will only use the name field for equals() and hashCode(), ignoring the age field.

You can also include callSuper = true in the annotation to include fields from the superclass in the comparison:

@EqualsAndHashCode(callSuper = true)
public class Employee extends Person {
    private String employeeId;

    public Employee(String name, int age, String employeeId) {
        super(name, age);
        this.employeeId = employeeId;
    }
}

This ensures that the fields from both Person and Employee are used in equals() and hashCode().

Conclusion

The equals() and hashCode() methods are fundamental in Java for comparing objects and ensuring correct behavior in hash-based collections like HashMap and HashSet. Correctly overriding these methods is crucial for avoiding issues like duplicate objects or incorrect retrievals from collections.

Best practices include ensuring consistency between equals() and hashCode(), adhering to symmetry, reflexivity, and transitivity in equals(), and handling null values carefully. Using Objects.equals() and Objects.hash() can simplify implementation and avoid common pitfalls.

For developers seeking to reduce boilerplate code, Lombok’s @EqualsAndHashCode annotation is a powerful tool. It automatically generates equals() and hashCode() methods, allowing for customization and ensuring that your code remains clean and maintainable.

In conclusion, mastering equals() and hashCode() is essential for any Java developer working with collections, and tools like Lombok can greatly enhance productivity while ensuring correctness.

What is optional ?

At its core, Optional is a wrapper for a value that may or may not be present. It helps developers avoid common issues with null, such as NullPointerException, by forcing the handling of optional values.

Optional<String> optionalValue = Optional.of("Hello, Java!");

In this example, optionalValue is an Optional that contains a non-null value. If you pass null to the of method, it throws a NullPointerException. For cases where null is valid, you can use Optional.ofNullable().

Optional<String> optionalValue = Optional.ofNullable(null);

With Optional, the intent of "this value might be absent" is explicit, and handling such cases becomes more predictable and less error-prone.

Methods in Optional<T>

The Optional class has a wide range of methods, each designed to handle optional values elegantly. Let's break down all the key methods and explore their purpose:

1. Static Factory Methods

• empty():

  Returns an empty Optional instance.

    Optional<String> emptyOptional = Optional.empty();
  

• of(T value):

  Returns an Optional with the specified non-null value.

    Optional<String> opt = Optional.of("value");
  

• ofNullable(T value):

  Returns an Optional describing the specified value, or an empty Optional if the value is null.

    Optional<String> opt = Optional.ofNullable(null);
  

2. Basic Methods for Value Handling

• get():

  If a value is present, returns the value. Otherwise, throws NoSuchElementException.

• isPresent():

  Returns true if the value is present, otherwise false.

• isEmpty() (Java 11):

  Returns true if the Optional is empty, otherwise false.

3. Value Retrieval with Default Handling

• orElse(T other):

  Returns the value if present, otherwise returns other.

• orElseGet(Supplier<? extends T> other):

  Returns the value if present, otherwise calls the Supplier and returns its result.

• orElseThrow():

  Returns the contained value if present, otherwise throws NoSuchElementException.

• orElseThrow(Supplier<? extends X> exceptionSupplier):

  Returns the value if present, otherwise throws an exception produced by the Supplier.

4. Conditional Execution Methods

• ifPresent(Consumer<? super T> action):

  If a value is present, performs the given action with the value.

• ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) (Java 9):

  If a value is present, performs the action with the value; otherwise, runs the emptyAction.

5. Mapping Methods

• map(Function<? super T, ? extends U> mapper):

  If a value is present, applies the provided mapping function to it and returns a new Optional with the result.

• flatMap(Function<? super T, Optional<U>> mapper):

  Similar to map(), but the mapper function must return an Optional.

• filter(Predicate<? super T> predicate):

  If a value is present and it matches the given predicate, returns an Optional describing the value; otherwise, returns an empty Optional.

6. Stream and Iteration

• stream() (Java 9):

  If a value is present, returns a Stream containing the value; otherwise, returns an empty Stream.

Best Practices for Using Optional

• Avoid using Optional for fields/parameters: Optional was designed for return types and not as a type for class members or arguments for methods. Using Optional in fields/parameters can lead to unnecessary complications.

• Use Optional for method return types: It's an excellent choice for methods that might return null. It forces the caller to handle the absent case explicitly.

• Do not use Optional.get(): I can't stress this enough, but this method defeats the purpose of using Optional, as it reintroduces the risk of NoSuchElementException. Prefer safer alternatives like orElse(), orElseThrow(), or ifPresent().

• Use ifPresentOrElse() for clear fallback logic: This method is particularly useful when you need to handle both the presence and absence of a value with different actions.

Clean code example with Optional

1. No null check

The following code get the name of a user using his id, if the user is not found we return null.
Old way of doing this :

public String getNameById(int id) {
    User user = findUserById(id);
    if(user == null) return null;
    return user.getName();
}

Using Optional, we can see clearly from the method signature that the result might be absent. The code is more expressive, and the use of map() eliminates explicit null checks, making it more readable.

public Optional<String> getNameById(int id) {
    return Optional.ofNullable(findUserById(id))
                   .map(User::getName);
}

2. Chain methods not ifs

   The following code gets the company name from the user entity. It gets the adress then the company then the company name. If a null is found it returns “unknown”.

public String getCompanyName(User user) {
    if (user != null) {
        Address address = user.getAddress();
        if (address != null) {
            Company company = address.getCompany();
            if (company != null) {
                return company.getName();
            }
        }
    }
    return "Unknown";
}

Optional does a magnificent job in making this kind of use cases simple.

public String getCompanyName(User user) {
    return Optional.ofNullable(user)
                   .map(User::getAddress)
                   .map(Address::getCompany)
                   .map(Company::getName)
                   .orElse("Unknown");
}

By using the Optional API we avoided using multiple if statments.

Conclusion

The Optional<T> class provides a powerful and expressive way to handle potential absence of values in Java. Its methods are designed to encourage a functional programming style, reducing the need for null checks and making your code cleaner and safer. With its rich API, you can handle optional values in multiple ways, each designed to fit specific use cases.

Understanding how to effectively use Optional can drastically improve the readability and reliability of your Java applications. Whether you're working with legacy code or developing new systems, integrating Optional in return types helps signal the possibility of missing values in a clear and type-safe way.

While you can't reassign the record's fields, the objects they reference, like mutable collections, can still be modified. This creates an illusion of immutability—where the record's structure looks immutable, but its contents can still change, going against the main idea of immutability that records aim to promote.

In this article, we'll look at why Java records might not be as immutable as they seem, especially with mutable collections, and discuss ways to handle this issue.

Understanding Java Records: A Quick Recap

At its core, a record is a special kind of class in Java:

public record User(String name) {}

This User record automatically generates the following:

• A constructor to initialize the field name.

• Accessor method name().

• equals(), hashCode(), and toString() methods.

You might think that since the fields are final, the object is fully immutable. However, immutability only applies to the references stored in those fields, not to the objects they point to.

The Problem: Mutable Objects

Let’s extend our User example to include a List<String> to store phone numbers:

import java.util.List;

public record User(String name, List<String> phoneNumbers) {}

On the surface, this seems immutable because we can’t reassign phoneNumbers to a different list. But the real problem lies in the fact that List<String> itself is mutable/immutable depending on the implementation we choose to use, for demonstration purpuses, we will be using the ArrayList (a mutable collection) implementation:

public class Main {
    public static void main(String[] args) {
        List<String> phoneNumbers = new ArrayList<>();
        phoneNumbers.add("+33 613-56-91-91");

        var user = new User("John", phoneNumbers);
        System.out.println(person.phoneNumbers()); // [+33 613-56-91-91]

        // Mutating the list from outside the 
        user.phoneNumbers().add("+33 615-25-40-49");
        System.out.println(user.phoneNumbers()); // [+33 613-56-91-91, +33 615-25-40-49]
    }
}

The record guarantees that the reference to phoneNumbers is immutable, but the contents of the list can still be changed. This breaks the illusion of immutability, as the User object can be modified indirectly.

To illustrate the immutability of the reference, let’s take a look at this code :

public static void main(String[] args) {
        List<String> phoneNumbers = new ArrayList<>();
        phoneNumbers.add("+33 613-56-91-91");

        var user = new User("John", phoneNumbers);

        // error: cannot assign a value to final variable phoneNumbers
        user.phoneNumbers = new ArrayList<>(user.phoneNumbers());
    }

Why Does This Happen?

Java’s immutability for records only applies to fields themselves, not to the objects those fields reference. Since List is mutable, we can modify its contents even though the reference itself is final. This applies to any mutable Object.

The mutability issue arises because collections in Java, by default, do not enforce immutability. While you can't reassign a new list to phoneNumbers in the User record, you can modify the list itself.

Alternatives: Enforcing Immutability

To preserve true immutability with mutable Collections inside a record, you have a few options:

1. Defensive Copying

One common approach is to make a defensive copy of the collection during record initialization. This ensures that even if the original collection is mutable, the copy stored in the record is isolated from external modifications. This can be achieved by adding the following code to the canonical constructor of the User record.

import java.util.List;
import java.util.ArrayList;
import java.util.Collections;

public record User(String name, List<String> phoneNumbers) {
    public User{
        // Defensive copy
        phoneNumbers = List.copyOf(phoneNumbers);
    }
}

In this example, List.copyOf(addresses) creates an unmodifiable copy of the input list. Any attempts to modify this copy will result in UnsupportedOperationException.

2. Using Unmodifiable Collections

If you’re dealing with a collection that should never be modified, you can use Java's unmodifiable collections:

javaCopy codeimport java.util.List;
import java.util.Collections;

public record Person(String name, int age, List<String> addresses) {
    public Person {
        // Wrapping the list as unmodifiable
        addresses = Collections.unmodifiableList(new ArrayList<>(addresses));
    }
}

Here, Collections.unmodifiableList() returns a read-only view of the list. While you can still pass a mutable list into the record, the record itself will only expose an unmodifiable version, preventing external changes.

3. Generic alternative :

If you need to maintain mutability outside of the record—meaning that the objects returned by the getters are still mutable but cannot affect the record’s internal state—you can achieve this by making defensive copies both during the record's initialization and in the getter method. This approach ensures that any mutations performed on the returned object don't affect the record’s internal data. Let’s look at the updated User record code :

public record User(String name, List<String> phoneNumbers) {

    // Defensive copy in the constructor
    public User {
        // Create a defensive copy to prevent external modifications
        addresses = new ArrayList<>(addresses);
    }

    // Defensive copy in the getter
    @Override
    public List<String> addresses() {
        // Return a mutable copy of the addresses
        return new ArrayList<>(addresses);
    }
}

Now let’s run our code :

public class Main {
    public static void main(String[] args) {
        List<String> phoneNumbers = new ArrayList<>();
        phoneNumbers.add("+33 613-56-91-91");

        var user = new User("John", phoneNumbers);
        System.out.println(person.phoneNumbers()); // [+33 613-56-91-91]

        // Mutating the list from outside the record
        user.phoneNumbers().add("+33 615-25-40-49");
        System.out.println(user.phoneNumbers()); // [+33 613-56-91-91]
    }
}

Conclusion

While Java records are designed to simplify the creation of immutable data classes, the immutability they promise can be misleading when dealing with mutable objects. Since objects like ArrayList remain mutable, they can undermine the immutability of records.

To address this, you can adopt several strategies:

• Defensive copying.

• Using unmodifiable collections provided by Java’s Collections utility class (Collection specific sollution).

• Returning a copy of the object.

By incorporating these approaches, you can ensure that your Java records live up to the promise of immutability, even when mutable Objects are involved.

In this article, we will explore what Records are, how they work, why to use them, and most importantly, when to use them.

What are Java Records?

Records are a special kind of classes designed mainly to hold immutable data. It automatically generate the necessary methods for basic data handling, which helps reduces the amount of boiler plate commonly associated with plain java objects, such as constructors, getters, toString(), hashCode(), and equals() methods. By default Records in java are immutable, once created the data it holds cannot be changed.

Syntax

Let's create a Book class in the traditional Java way. Our class Book should have a title, a price, an ISBN and finally the authors name.

import java.util.Objects;

public class Book {
    private final String title;
    private final double price;
    private final String isbn;
    private final String authorName;

    public Book(String title, double price, String isbn, String authorName) {
        this.title = title;
        this.price = price;
        this.isbn = isbn;
        this.authorName = authorName;
    }

    public String getTitle() {
        return title;
    }

    public double getPrice() {
        return price;
    }

    public String getIsbn() {
        return isbn;
    }

    public String getAuthorName() {
        return authorName;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Book book = (Book) o;
        return Double.compare(book.price, price) == 0 &&
                title.equals(book.title) &&
                isbn.equals(book.isbn) &&
                authorName.equals(book.authorName);
    }

    @Override
    public int hashCode() {
        return Objects.hash(title, price, isbn, authorName);
    }

    @Override
    public String toString() {
        return "Book{" +
                "title='" + title + '\'' +
                ", price=" + price +
                ", isbn='" + isbn + '\'' +
                ", authorName='" + authorName + '\'' +
                '}';
    }
}

Phew ! that's a lot of code lines for such a simple class.

NB: We use the final keyword in this example to ensure the immutablity.

Let's try to do the same but this time with records

public record Book(String title, double price, String isbn, String authorName) {}

And yes, it's as simple as that. Java will handle generating the constructor, the getters, the hash, equals, and toString methods. No setters are needed because records are immutable.

Why Use Records?

• Immutability by Design : Records are immutable, which makes them ideal for thread safe data transfer.

• Reduced Boilerplate Code: Records automatically generate the data handling methods, drastically reducing the boilerplate code, making the classes easier to maintain and read.

Some use cases

• Data Transfer Objects(DTOs) : DTOs are simple objects that move data between different parts of an application, like in REST APIs, service layers, or database queries. Records are great for this because of their built in immutability.

• Return Types for Methods: Record can be used to bundle values from multiple related data source.This eliminates the need for verbose classes or cumbersome return types like maps or arrays.

Records and data validation

Although Records automatically generate constructors and methods, you can still customize their behavior if needed. For example, you can define additional methods inside a Record or provide custom validation logic.

For example, a Book cannot have a negative price. Fortunately, Java has thought of this and introduced the canonical constructor.

public record Book(String title, double price, String isbn, String authorName) {

    // Canonical constructor
    public Book {
        if (price < 0) {
            throw new IllegalArgumentException("Price cannot be negative");
        }
    }
}

If we take a look at the generated code, the Book.class file we'll find this constructor.

public Book(String title, double price, String isbn, String authorName) {
            if (price < 0.0) {
                throw new IllegalArgumentException("Price cannot be negative");
            } else {
                this.title = title;
                this.price = price;
                this.isbn = isbn;
                this.authorName = authorName;
            }
        }

The code we put in the canonical constructor was inserted into the generated constructor.

Limitations

While Records are useful, they are not suitable for all situations and have some limitations :

• Immutability : Records cannot be used if you need mutable data structures like a database entity. In that case a traditional java class would be more appropriate

• No Inheritance: Records can implement interfaces; however, they cannot extend other classes because they already extend the Record class. We can see that if we inspect the bytecode using the javap -c command.

    public final class Book extends java.lang.Record {
      private final java.lang.String title;
    // the rest is hidden
  

Conclusion

Java Records offer a simple and modern way to handle data by reducing boilerplate code, ensuring immutability, and making code easier to read. They come with built-in equals(), hashCode(), and toString() methods, making them great for data transfer objects, method return types, and configuration classes.

Although they have some limitations, their ease of use and power make them a useful tool for Java developers. As Java evolves, Records will likely become a common pattern for managing simple, unchangeable data structures, helping us developers write cleaner and more maintainable code.