sealed classes, records and enums

Sometimes we write something for the book, only to realize it shouldn’t be in the book. This post is an example. Do you think this legal?

public sealed interface MySealedClass permits MyRecord, MyEnum {
}

record MyRecord() implements MySealedClass {}

enum MyEnum implements MySealedClass { VALUE }

It is! A sealed interface can be implemented by any Java type. Which means records and enums are included.

Using a Local Record for Readability

Sometimes there is something we really want to put in our cert book that doesn’t fit. You can only have so many case studies/real world scenarios after all. I rescued this from the trash heap and made this blog post./

Suppose we want to count the number of names that have both a first and last name beginning with E. We want to call the method as:

var names = List.of("Sarah Smith", "Eve Edwards");
System.out.println(local.countNamesStartingWithEs(names));

We can read this with streams:

public long countNamesStartingWithEs(List<String> names) {
   return names.stream()
      .map(t -> t.split(" "))
      .filter(a -> a[0].startsWith("E"))
      .filter(a -> a[1].startsWith("E"))
      .count();
}

The code works. However, it has array positions sprinkled throughout. This requires you to keep remembering the format. We can refactor using a local record:

public long countNamesStartingWithEsWithRecords(List<String> names) {
   record Name(String first, String last) {}

   return names.stream()
      .map(t -> t.split(" "))
      .map(t -> new Name(t[0], t[1]))
      .filter(n -> n.first().startsWith("E"))
      .filter(n -> n.last().startsWith("E"))
      .count();
    }

The record lets us give the fields names so we can reference them as n.first() and n.last(). The only place that has to know about the order is the call record constructor. For such a simple example, the approaches are similar. For longer and more complex pipelines, the local record approach can make the code easier to read.

why java records aren’t quite immutable

A new type called a “record” was previewed in Java 14 and released in Java 16. One of the benefits is that it creates immutable objects. Kind of.

An immutable record

This is record is an immutable object. Since it is a record, it is automatically final and has no setters. All is good.

public record Book (String title, int numPages) { }

A mutable record

There there is this record. Do you see why it is mutable?

public record Book (String title, int numPages, List<String> chapters) { }

The problem is that records use shallow immutability. The caller can’t change the “chapters” object to a different reference. The caller can change the values in the “chapters” to their heart’s content. That means this object is still mutable.

Here’s an example showing that the code prints [1, 2, 3] and therefore changes the list of chapters.

List<String> chapters = new ArrayList<>();
chapters.add("1");

Book book = new Book("Breaking and entering", 289, chapters);

chapters.add("2");
book.chapters().add("3");
System.out.println(book.chapters());

Making the record actually be immutable

It’s pretty easy to make the Book record actually be immutable. In fact, it only requires three extra lines! Records have a compact constructor which takes care of the setting fields for you. However, you can choose to change that behavior. In this example, I rely on the default set of “title” and “numPages”. However, for “chapters”, I choose to make an immutable copy to prevent changing the list.

public record Book (String title, int numPages, List<String> chapters) {

    public Book {
        chapters = List.copyOf(chapters);
    }
}

Now the test program fails with an UnsupportedOperationException. Much better. A real immutable record.