As a Java developer who has spent countless hours writing and maintaining code, I’ve always appreciated features that make my life easier. When Java introduced records and pattern matching, it felt like a breath of fresh air. These tools help reduce the tedious parts of coding, letting me focus on what matters—solving problems and building robust applications. In this article, I’ll walk you through how to use Java records and pattern matching in practical ways, with plenty of code examples to illustrate each point. Think of this as a friendly guide, whether you’re new to these concepts or looking to refine your skills.

Let’s start with the basics. Java records are a simple way to define classes that primarily hold data. Before records, I often wrote classes with fields, constructors, getters, equals, and hashCode methods—it was repetitive and error-prone. With records, you can declare a data holder in one line. For example, defining a Person record with a name and age is straightforward. The compiler handles the rest, generating all the necessary methods behind the scenes. This means less code to write and fewer bugs to chase down. I’ve found that using records makes my code cleaner and easier to read, especially when working with teams where clarity is key.

Here’s a basic record declaration:

public record Person(String name, int age) { }

This single line creates a class with a constructor, accessor methods for name and age, and implementations of equals, hashCode, and toString. It’s perfect for situations where you need a simple data container without extra logic. In my projects, I use records for things like configuration objects or API request bodies—anywhere I want immutability and simplicity.

Now, what if you need to add some validation? Records allow custom constructors to enforce rules. Suppose you want to ensure that a person’s age isn’t negative. You can add a compact constructor to handle this. The beauty here is that you don’t have to manually assign fields; the compiler does that for you. I use this all the time to catch errors early, like invalid user inputs, without cluttering my code with if-else statements.

Consider this example:

public record Person(String name, int age) {
    public Person {
        if (age < 0) throw new IllegalArgumentException("Age must be non-negative");
    }
}

In this code, the constructor checks the age before the object is created. If someone tries to make a Person with a negative age, it throws an exception immediately. This approach keeps my data integrity high and my code straightforward.

Moving on to pattern matching, it’s a feature that simplifies type checks and casts. Remember the old way of using instanceof followed by a cast? It was clunky and prone to mistakes. With pattern matching, you can do both in one step. For instance, if you have an object and want to check if it’s a String, you can declare a variable right in the condition. This makes the code more concise and less error-prone. I’ve used this to clean up legacy code where type checks were scattered everywhere.

Here’s how it works:

if (obj instanceof String s) {
    System.out.println(s.length());
}

In this snippet, if obj is a String, it’s automatically assigned to the variable s, and you can use it directly. No extra casting needed. It’s a small change, but it adds up in larger codebases, making everything feel smoother.

Pattern matching really shines in switch expressions. Instead of writing long if-else chains, you can use switch to handle different types elegantly. The compiler helps by ensuring you cover all possible cases, which I appreciate because it reduces runtime errors. In one of my applications, I used this to process various data types from an external source, and it made the code much more maintainable.

Take a look at this example:

String describe(Object obj) {
    return switch (obj) {
        case Integer i -> "Integer: " + i;
        case String s -> "String: " + s;
        default -> "Unknown";
    };
}

This method takes an object and returns a description based on its type. If it’s an Integer or String, it includes the value; otherwise, it defaults to “Unknown”. I find this style expressive and easy to extend when new types come along.

Combining records with sealed classes is another powerful technique. Sealed classes restrict which other classes can extend them, which is great for modeling fixed hierarchies. When you use records as the implementing classes, it enforces a clear structure. I’ve applied this in domains like geometry, where shapes have specific types, and it prevents unexpected subclasses from causing issues.

Here’s a simple setup:

public sealed interface Shape permits Circle, Rectangle { }
public record Circle(double radius) implements Shape { }
public record Rectangle(double width, double height) implements Shape { }

In this code, Shape can only be implemented by Circle and Rectangle. This makes pattern matching safe because you know all possible types. For example, when processing shapes, you can handle each case without worrying about unknown subtypes.

When you use pattern matching with records, you can deconstruct them to access their components directly. This is handy for extracting data without calling methods explicitly. In a recent project, I used this to calculate areas for different shapes, and it felt natural and efficient.

For instance:

if (shape instanceof Circle c) {
    double area = Math.PI * c.radius() * c.radius();
}

Here, if shape is a Circle, you get access to its radius immediately. It’s a clean way to work with data, and I’ve found it reduces the cognitive load when reading code.

Records integrate well with Java’s collection processing, especially with streams. If you have a list of records, you can easily transform or filter them using functional programming techniques. This is something I do daily—like extracting names from a list of Person records. The concise syntax of records pairs perfectly with streams, making data pipelines more readable.

Consider this example:

List<Person> people = List.of(new Person("Alice", 30), new Person("Bob", 25));
List<String> names = people.stream().map(Person::name).collect(Collectors.toList());

This code creates a list of Person records, then uses a stream to extract just the names into a new list. It’s efficient and easy to understand, which is why I recommend using records in data-heavy applications.

Pattern matching also helps with null safety. Instead of scattering null checks throughout your code, you can handle them explicitly in patterns. This centralizes error handling and makes your code more robust. I’ve used this in APIs where input data might be null, and it’s saved me from many potential crashes.

Here’s how you can do it:

String process(Object input) {
    return switch (input) {
        case null -> "Null input";
        case String s -> "String: " + s;
        case Integer i -> "Integer: " + i;
    };
}

In this method, null is treated as a separate case, so you don’t forget to handle it. It’s a simple yet effective way to make your code safer.

Another useful combination is records with Optional. This is great for methods that might not always return a value, like database queries. By wrapping records in Optional, you signal that the result could be absent, which encourages callers to handle that case. I use this pattern to build null-safe APIs that are clear and predictable.

For example:

public record User(String username, String email) { }
Optional<User> findUser(String id) {
    return Optional.ofNullable(fetchUser(id));
}

Here, findUser returns an Optional that might contain a User record. If fetchUser returns null, the Optional is empty, and you can deal with it appropriately. This has made my code more resilient to missing data.

Finally, records work excellently as data transfer objects (DTOs) in web APIs, such as with Spring Boot. They provide immutability and reduce boilerplate, which is perfect for REST endpoints. In my experience, using records for request and response bodies simplifies serialization and makes the API contracts clear.

Here’s a Spring controller example:

@RestController
public class UserController {
    @PostMapping("/users")
    public User createUser(@RequestBody User user) {
        return userRepository.save(user);
    }
}

In this code, the User record is used directly in the controller method. Spring handles the JSON serialization automatically, and because records are immutable, you avoid accidental modifications. I’ve deployed this in production apps, and it’s held up well under load.

Throughout my journey with Java, I’ve seen how records and pattern matching can transform code from verbose and error-prone to concise and reliable. By adopting these techniques, you’ll write less code, reduce bugs, and make your applications easier to maintain. Remember, the goal isn’t just to use new features but to solve real problems more effectively. I encourage you to experiment with these examples in your own projects—you might be surprised at how much they improve your workflow. If you have questions or want to share your experiences, I’d love to hear how it goes for you. Happy coding!