Dangers of Null#

Let’s start with an example to see the dangers of null by considering a nested object structure for a Computer, as illustrated in Figure below

What’s possibly problematic with the following code?

1
String version = computer.getSoundcard().getUSB().getVersion();

This code looks pretty reasonable. However, many computers (for example, the Raspberry Pi) don’t actually ship with a sound card. So what is the result of getSoundcard()?

A common (bad) practice is to return the null reference to indicate the absence of a sound card. Unfortunately, this means the call to getUSB() will try to return the USB port of a null reference, which will result in a NullPointerException at runtime and stop our program from running further. Imagine if our program was running on a customer’s machine; what would our customer say if the program suddenly failed?

To give some historical context, Tony Hoare - one of the giants of computer science - wrote, “I call it my billion-dollar mistake. It was the invention of the null reference in 1965. I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement.”

What can we do to prevent unintended null pointer exceptions? We can be defensive and add checks to prevent null dereferences, as shown below:

1
String version = "UNKNOWN";
2
if (computer != null) {
3
    Soundcard soundcard = computer.getSoundcard();
4
    if(soundcard != null){
5
        USB usb = soundcard.getUSB();
6
        if(usb != null){
7
            version = usb.getVersion();
8
        }
9
    }
10
}

However, we can see that the code quickly becomes very ugly due to the nested checks. Unfortunately, we need a lot of boilerplate code to make sure we don’t get a NullPointerException. In addition, it’s just annoying that these checks get in the way of the business logic. In fact, they are decreasing the overall readability of our program.

Furthermore, it is an error-prone process; what if we forget to check that one property could be null? I will argue in this post that using null to represent the absence of a value is a wrong approach. What we need is a better way to model the absence and presence of a value.

To give some context, let’s briefly look at what other programming languages have to offer.

What Alternatives to Null Are There#

Languages such as Groovy have a safe navigation operator represented by ”?.” to safely navigate through potential null references. (Note that it is soon to be included in C#, too, and it was proposed for Java SE 7 but didn’t make it into that release.) It works as follows:

1
String version = computer?.getSoundcard()?.getUSB()?.getVersion()

In this case, the variable “version” will be assigned to null if computer is null, or getSoundcard() returns null, or getUSB() returns null. We don’t need to write complex nested conditions to check for null.

In addition, Groovy also includes the Elvis operator ”?:” (if we look at it sideways, we’ll recognize Elvis’ famous hair), which can be used for simple cases when a default value is needed. In the following, if the expression that uses the safe navigation operator returns null, the default value “UNKNOWN” is returned; otherwise, the available version tag is returned.

1
String version = computer?.getSoundcard()?.getUSB()?.getVersion() ?: "UNKNOWN"

Other functional languages, such as Haskell and Scala, take a different view. Haskell includes a Maybe type, which essentially encapsulates an optional value. A value of type Maybe can contain either a value of a given type or nothing. There is no concept of a null reference. Scala has a similar construct called Option[T] to encapsulate the presence or absence of a value of type T. We then have to explicitly check whether a value is present or not using operations available on the Option type, which enforces the idea of “null checking.” We can no longer “forget to do it” because it is enforced by the type system.

Java 8 Optional in a Nutshell#

Java SE 8 introduces a new class called java.util.Optional<T> that is inspired from the ideas of Haskell and Scala. It is a class that encapsulates an optional value, as illustrated in figure below. We can view Optional as a single-value container that either contains a value or doesn’t (it is then said to be “empty”):

We can update our model to make use of Optional, as shown in Listing 2:

1
public class Computer {
2

3
    private Optional<Soundcard> soundcard;
4

5
    public Optional<Soundcard> getSoundcard() { ... }
6
    ...
7
}
8

9
public class Soundcard {
10

11
    private Optional<USB> usb;
12

13
    public Optional<USB> getUSB() { ... }
14
}
15

16
public class USB {
17

18
    public String getVersion(){ ... }
19
}

The code above immediately shows that a computer might or might not have a sound card (the sound card is optional). In addition, a sound card can optionally have a USB port. This is an improvement, because this new model can now reflect clearly whether a given value is allowed to be missing.

But what can we actually do with an Optional<Soundcard> object? After all, we want to get to the USB port’s version number. In a nutshell, the Optional class includes methods to explicitly deal with the cases where a value is present or absent. However, the advantage compared to null references is that the Optional class forces us to think about the case when the value is not present. As a consequence, we can prevent unintended null pointer exceptions.

It is important to note that the intention of the Optional class is not to replace every single null reference. Instead, its purpose is to help design more-comprehensible APIs so that by just reading the signature of a method, we can tell whether we can expect an optional value. This forces us to actively unwrap an Optional to deal with the absence of a value.

Using Optional#

The Groovy code above can be written with Optional in Java as

1
String name = computer.flatMap(Computer::getSoundcard)
2
        .flatMap(Soundcard::getUSB)
3
        .map(USB::getVersion)
4
        .orElse("UNKNOWN");

1
Optional<Soundcard> sc = Optional.empty();

1
Optional<Soundcard> sc = Optional.of(new Soundcard());

1
Optional<Soundcard> sc = Optional.ofNullable(soundcard);

1
SoundCard soundcard = ...;
2
if(soundcard != null){
3
    System.out.println(soundcard);
4
}

1
Optional<Soundcard> soundcard = ...;
2
soundcard.ifPresent(System.out::println);

1
if(soundcard.isPresent()){
2
    System.out.println(soundcard.get());
3
}

1
Soundcard soundcard = maybeSoundcard != null ? maybeSoundcard : new Soundcard("basic_sound_card");

1
Soundcard soundcard = maybeSoundcard.orElse(new Soundcard("defaut"));

1
Soundcard soundcard = maybeSoundCard.orElseThrow(IllegalStateException::new);

1
USB usb = ...;
2
if(usb != null && "3.0".equals(usb.getVersion())){
3
    System.out.println("ok");
4
}

1
Optional<USB> maybeUSB = ...;
2
maybeUSB.filter(usb -> "3.0".equals(usb.getVersion()).ifPresent(() -> System.out.println("ok"));

1
if(soundcard != null){
2
    USB usb = soundcard.getUSB();
3
    if(usb != null && "3.0".equals(usb.getVersion()){
4
        System.out.println("ok");
5
    }
6
}

1
Optional<USB> usb = maybeSoundcard.map(Soundcard::getUSB);

1
maybeSoundcard.map(Soundcard::getUSB)
2
        .filter(usb -> "3.0".equals(usb.getVersion())
3
        .ifPresent(() -> System.out.println("ok"));

1
String version = computer.getSoundcard().getUSB().getVersion();

1
String version = computer.map(Computer::getSoundcard)
2
        .map(Soundcard::getUSB)
3
        .map(USB::getVersion)
4
        .orElse("UNKNOWN");

1
String version = computer.flatMap(Computer::getSoundcard)
2
        .flatMap(Soundcard::getUSB)
3
        .map(USB::getVersion)
4
        .orElse("UNKNOWN");

Combining a Collection of Predicates#

We chain a collection of Predicates by reducing them. In the following example, we have a list of predicates that we combined using Predicate.and():

1
@Test
2
public void whenFilterListWithCollectionOfPredicatesUsingAnd_thenSuccess(){
3
    List<Predicate<String>> allPredicates = new ArrayList<Predicate<String>>();
4
    allPredicates.add(str -> str.startsWith("A"));
5
    allPredicates.add(str -> str.contains("d"));
6
    allPredicates.add(str -> str.length() > 4);
7

8
    List<String> result = names.stream()
9
        .filter(allPredicates.stream().reduce(x->true, Predicate::and))
10
        .collect(Collectors.toList());
11

12
    assertEquals(1, result.size());
13
    assertThat(result, contains("Alexander"));
14
}

Note that we use our base identity as:

1
x->true

That will be, however, different if we want to combine them using Predicate.or():

1
@Test
2
public void whenFilterListWithCollectionOfPredicatesUsingOr_thenSuccess(){
3
    List<String> result = names.stream()
4
        .filter(allPredicates.stream().reduce(x->false, Predicate::or))
5
        .collect(Collectors.toList());
6

7
    assertEquals(2, result.size());
8
    assertThat(result, contains("Adam","Alexander"));
9
}

Collecting Stream containing “null” to List#

1
person.stream()
2
        .sorted(Comparator.comparingInt(Person::getDriverLicense))
3
        .collect(Collectors.toList());

If this stream contains a kid who doesn’t know how to drive, the Collectors.toList() might see a null value, which causes NullPointerException, because Collectors.toList() gives us a list implementation that doesn’t permit null elements. ArrayList, however, permits null elements according to its JavaDoc. The solution them would be

1
person.stream()
2
        .sorted(Comparator.comparingInt(Person::getDriverLicense))
3
        .collect(Collectors.toCollection(ArrayList::new));

Note that the last line is changed so that the collect procedure returns an uer-specified list implementation, which is ArrayList

Sorting#

1
public class User {
2

3
    private final String name;
4
    private final int age;
5
}
6

7
final List<User> users = Arrays.asList(
8
        new User("C", 30),
9
        new User("D", 40),
10
        new User("A", 10),
11
        new User("B", 20),
12
        new User("E", 50)
13
);
14

15
List<User> sortedList = users.stream()
16
            .sorted(Comparator.comparingInt(User::getAge))
17
            .collect(Collectors.toList());

Remove Duplicates from a List of Objects based on Property#

You can get a stream from the List and put in in the TreeSet from which you provide a custom comparator that compares the property uniquely. Then if you really need a list you can put then back this collection into an ArrayList:

1
import static java.util.Comparator.comparingInt;
2
import static java.util.stream.Collectors.collectingAndThen;
3
import static java.util.stream.Collectors.toCollection;
4

5
...
6
List<Employee> unique = employee.stream()
7
        .collect(
8
                collectingAndThen(
9
                        toCollection(() -> new TreeSet<>(comparingInt(Employee::getId))),
10
                        ArrayList::new
11
                )
12
        );

Given the example:

1
List<Employee> employee = Arrays.asList(new Employee(1, "John"), new Employee(1, "Bob"), new Employee(2, "Alice"));

It will output:

1
[Employee{id=1, name='John'}, Employee{id=2, name='Alice'}]

Convert Iterable to Stream#

1
StreamSupport.stream(iterable.spliterator(), false)
2
        .filter(...)
3
        .moreStreamOps(...);

Convert Two Dimensional Array to List#

1
List<Foo> collection = Arrays.stream(array)  //'array' is two-dimensional
2
        .flatMap(Arrays::stream)
3
        .collect(Collectors.toList());

Preserve Order in Stream with collect#

Say we would like to process a list such as [“blah”, “blah”, “yep”] and get [“blah (2 times)”, “yep”], we will collect them to a LinkedHashMap to get the expected result:

1
return messages.stream()
2
        .collect(groupingBy(Function.identity(), LinkedHashMap::new, summingInt(e -> 1)))
3
        .entrySet()
4
        .stream()
5
        .map(e -> e.getKey()+(e.getValue() == 1 ? "" : " (" + e.getValue() +" times)"))
6
        .collect(toList());

Pattern-Based Filter (System Property Example)#

This example demonstrates how to set a global filter using the jdk.serialFilter system property to allow only classes within com.example.allowed and reject all others.

If the JDK system property has been set with -Djdk.serialFilter="com.example.allowed.*;!*", the following runtime should execute successfully without error for AllowedClass and throw exception for RestrictedClass:

1
import java.io.ByteArrayInputStream;
2
import java.io.ByteArrayOutputStream;
3
import java.io.IOException;
4
import java.io.ObjectInputStream;
5
import java.io.ObjectOutputStream;
6
import java.io.Serializable;
7

8
public static void serialize(Serializable obj, Class<? extends Serializable> clazz) {
9
    try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)) {
10
        oos.writeObject(obj);
11

12
        try (ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
13
             ObjectInputStream ois = new ObjectInputStream(bis)) {
14
            Serializable result = clazz.cast(ois.readObject());
15
        }
16
    } catch (IOException | ClassNotFoundException exception) {
17
        throw new IllegalStateException(exception);
18
    }
19
}
20

21
AllowedClass allowed = new AllowedClass("Hello Allowed!");
22
RestrictedClass restricted = new RestrictedClass("Secret Data!");
23

24
serialize(allowed, AllowedClass.class);       // ✅
25
serialize(restricted, RestrictedClass.class); // ❌ runtime error

Programmatic Filter (ObjectInputFilter API)#

This example shows how to set a filter directly on an ObjectInputStream using the ObjectInputFilter interface.

1
import java.io.ByteArrayInputStream;
2
import java.io.ByteArrayOutputStream;
3
import java.io.IOException;
4
import java.io.ObjectInputFilter;
5
import java.io.ObjectInputStream;
6
import java.io.ObjectOutputStream;
7
import java.io.Serializable;
8

9
public static void serialize(Serializable obj, Class<? extends Serializable> clazz) {
10
    try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)) {
11
        oos.writeObject(obj);
12

13
        try (ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
14
             ObjectInputStream ois = new ObjectInputStream(bis)) {
15

16
            ois.setObjectInputFilter(info -> {
17
                if (info.serialClass() != null && info.serialClass().getName().startsWith("com.example.allowed")) {
18
                    return ObjectInputFilter.Status.ALLOWED;
19
                }
20
                return ObjectInputFilter.Status.REJECTED;
21
            });
22

23
            Serializable result = clazz.cast(ois.readObject());
24
        }
25
    } catch (IOException | ClassNotFoundException exception) {
26
        throw new IllegalStateException(exception);
27
    }
28
}
29

30
AllowedClass allowed = new AllowedClass("Hello Allowed!");
31
RestrictedClass restricted = new RestrictedClass("Secret Data!");
32

33
serialize(allowed, AllowedClass.class);       // ✅
34
serialize(restricted, RestrictedClass.class); // ❌ runtime error

In this example, the setObjectInputFilter method is used on the ObjectInputStream to apply a lambda expression as the filter. This filter explicitly allows classes starting with com.example.allowed and rejects all others.

Why does NIO matter?#

Java NIO provides 2 main types of ByteBuffer: heap buffers and direct buffers. How they are managed by the garbage collector is fundamentally different.

• Heap Buffers (ByteBuffer.allocate)

  This buffer is essentially a wrapper around a standard Java byte[] array. Both the buffer object and the underlying byte array reside on the JVM heap

  Because it lives on the heap, a heap buffer is fully managed by the garbage collector. When the ByteBuffer object is no longer referenced by our application, it becomes eligible for garbage collection, and the GC will reclaim its memory just like any other Java object. This process is automatic and predictable within the normal workings of the GC.

• Direct Buffers (ByteBuffer.allocateDirect)

  Direct buffers are designed for high-performance I/O and behave very differently. A direct buffer allocates a block of memory outside the normal garbage-collected heap. This is often called “off-heap” or “native” memory. The JVM will try to perform native I/O operations directly on this memory, avoiding the overhead of copying data between the JVM heap and the native I/O layer.

  It gets tricky when it comes to garbage collection. The native memory block itself is not directly managed by the GC. However, the DirectByteBuffer object, which is a small Java object that acts as a reference to this native memory, does live on the JVM heap and is garbage collected. The JVM uses a special mechanism to free the native memory. When the DirectByteBuffer object on the heap becomes unreachable, the garbage collector will eventually process it. This action triggers a cleanup process (using an object called a Cleaner in modern Java versions) that deallocates the corresponding block of off-heap, native memory.

  This indirect management can cause problems. If our application creates many short-lived direct buffers, we might exhaust our available native memory and get an OutOfMemoryError: Direct buffer memory. This can happen even if our JVM heap has plenty of free space, because the garbage collector may not run frequently enough to clean up the DirectByteBuffer objects that would, in turn, free the native memory. For this reason, direct buffers are best suited for large, long-lived buffers where their performance benefits are most significant.

Understand such nuanced intricacies requires systematic study of the memory structure and allocation of JVM. For example, we need a firm grip in our mind on what’s actually happening in the “overhead of copying data between the JVM heap and the native I/O layer”. In addition, as a serious Java developer, Understanding the JVM’s internal memory management is the key to writing truly high-performance, resilient applications and diagnosing complex production issues. While there are many resources, one book is consistently recommended as the definitive modern guide, which is highly recommended, Java Performance: The Definitive Guide by Scott Oaks:

This book is perfectly suited for a developer who wants a systematic and practical understanding of the JVM. It discusses garbage collection theory, the specifics of different GC algorithms (like G1, ZGC, and Shenandoah), and the tools (like profilers and command-line utilities) we need to observe the JVM in action. It provides a clear path from theory to practice.

This book, however, doesn’t talk too much about JVM memory structure. For example, it just mentions “heap memory” without defining or describing what it is. Those who need another “definitive” walkthrough on JVM internal structure could pick up Inside the Java Virtual Machine by Bill Venners.

While performance guides tell us how to make it run faster, Venners’ book explains what it is and why it is designed that way.

CAUTION

This book is a classic, with the 2nd edition published in 1999 for Java 2. This means the conceptual explanations of the architecture are timeless and unparalleled, but the implementation details are outdated. We won’t find information on modern garbage collectors like G1/ZGC, the JIT compiler, or the transition from PermGen to Metaspace.

The best approach is to use this book to build our fundamental understanding of the JVM’s blueprint and then supplement it with modern resources for the specifics of the HotSpot JVM, such as Java Virtual Machine Specification, the blueprint from which all JVMs are built. It’s not a tutorial and can be a dense, formal read, but it is the ultimate source of truth.

Java NIO#

Understanding Java NIO (New Input/Output) is crucial for building high-performance, scalable applications, especially those dealing with network communication or large file operations. Introduced in Java 1.4, NIO provides an alternative and often more efficient way to handle I/O compared to the traditional java.io package. In particular

• Non-blocking IO: Java NIO enables us to do non-blocking IO. For instance, a thread can ask a channel to read data into a buffer. While the channel reads data into the buffer, the thread can do something else. Once data is read into the buffer, the thread can then continue processing it. The same is true for writing data to channels.
• Channels and Buffers: In the standard IO API we work with byte streams and character streams. In NIO we work with channels and buffers. Data is always read from a channel into a buffer, or written from a buffer to a channel.
• Selectors: Java NIO contains the concept of “selectors”. A selector is an object that can monitor multiple channels for events (like: connection opened, data arrived etc.). Thus, a single thread can monitor multiple channels for data.

Java NIO consist of the following core components:

• Channels
• Buffers
• Selectors

Java NIO has more classes and components than these, but the Channel, Buffer and Selector forms the core of the API. The rest of the components, like Pipe and FileLock are merely utility classes to be used in conjunction with the 3 core components. Let’s then focus on these 3 components for now. The other components are explained in their own texts further below

1
RandomAccessFile file = new RandomAccessFile("data.txt", "r");
2
FileChannel fileChannel = file.getChannel();
3
ByteBuffer buffer = ByteBuffer.allocate(512);
4

5
int bytesRead = fileChannel.read(buffer);
6
while (bytesRead != -1) {
7
    buffer.flip();
8

9
    while (buffer.hasRemaining()) {
10
        System.out.print((char) buffer.get());
11
    }
12

13
    buffer.clear();
14
    bytesRead = fileChannel.read(buffer);
15
}
16

17
fileChannel.close();
18
file.close();

What are Records NOT for#

First, we should be very clear about what Records are NOT for:

Non-Goal 1

“While records do offer improved concision when declaring data carrier classes, it is NOT a goal to declare a “war on boilerplate”. In particular, it is not a goal to address the problems of mutable classes which use the JavaBeans naming conventions.”

- OpenJDK Records

What are “Classes which use the JavaBeans Naming Conventions”? A traditional JavaBean is a standard Java class designed around a specific set of conventions:

• Private Fields: The internal data is hidden.
• A Public No-Argument Constructor: An empty constructor (new MyBean()) is required so frameworks can instantiate the object dynamically.
• Getters and Setters: Properties are accessed via getFoo() and modified via setFoo(value).

Because objects are created empty and populated afterward via setters, JavaBeans are inherently mutable.

What are the “Problems” of Mutable JavaBeans? While the JavaBean pattern became ubiquitous in enterprise Java (used extensively by frameworks, ORMs, and UI libraries), it suffers from several deep design flaws:

• Inconsistent (Half-Baked) States: When we instantiate a JavaBean using a no-arg constructor and call setters one by one, the object exists in a temporary, incomplete, or invalid state until all necessary setters have been invoked. If another thread reads the object midway, it sees corrupted or missing data.
• Loss of Immutability: Because fields are non-final and exposed to setters, any part of the application can modify the object’s state at any time. This makes tracking bugs, debugging race conditions, and writing thread-safe code extremely difficult.
• Verbosity and Boilerplate: Even with modern IDEs, writing or generating getters, setters, equals, hashCode, and toString methods creates massive amounts of boilerplate code.

Why is this a “Non-Goal” for Records? In a record, all fields are implicitly final, and values can only be set once - at the exact moment of construction. Records are immutable and do not have setter methods. JavaBeans, being mutable by design, rely entirely on mutability and setters to change state after construction. Because records are strictly immutable and require all data to be passed into the constructor upfront, they cannot act as drop-in replacements for mutable JavaBeans. If our architecture relies on objects being mutable, having empty default constructors, or being modified dynamically by frameworks, records will not solve those design patterns.

Non-Goal 2

“It is not a goal to add features such as properties or annotation-driven code generation, which are often proposed to streamline the declaration of classes for “Plain Old Java Objects”.”

- OpenJDK Records

What are “Properties” and “Annotation-Driven Code Generation” in traditional POJOs? In the traditional enterprise Java ecosystem (outside of the language core), developers grew tired of writing massive amounts of repetitive boilerplate code for standard data classes. To “streamline” this, 2 major mechanisms emerged:

1. Framework-defined “Properties”: Unlike languages like C#, Kotlin, or Swift which have first-class language properties built into their syntax, Java classes rely on naming conventions (getFoo/setFoo) to simulate properties. Because Java doesn’t have a native property concept, frameworks have to inspect classes via reflection at runtime to figure out what fields exist.
2. Annotation-Driven Code Generation (e.g., Project Lombok): Tools like Lombok use annotation processors (such as @Data, @Getter, @Setter, @ToString) during compilation to automatically inject getters, setters, and constructors into the bytecode so the developer doesn’t have to look at them.

Why is adding these features a “Non-Goal” for Records? When designing Records, the Java language architects deliberately chose a different philosophical path:

• Transparency over Magic: Records are designed to be “transparent carriers for data.” What we declare in the header is precisely what we get: no hidden fields, no auto-generated setters, and no runtime magic.

• Immutability over Mutable POJOs: POJOs are typically mutable (with getters and setters allowing state changes after creation). Records are strictly immutable. If the Java team tried to solve the “POJO problem,” they would have to support mutability, custom getters/setters, empty constructors, and flexible property mapping which completely contradicts what a record is (an immutable, nominal tuple).

  POJO v.s. JavaBean

  All JavaBeans are POJOs, but not all POJOs are JavaBeans.

  POJO (Plain Old Java Object) are standard Java object completely free of framework-specific restrictions. JavaBean is specialized POJO that adheres to strict coding conventions:

  	POJO	JavaBean
  Constructor	Can have any configuration of constructors (with or without arguments).	Must have a public, no-argument constructor.
  Properties & Visibility	Fields can use any access modifier (public, private, etc.).	Must have private fields accessed exclusively via public getters and setters.
  Serialization	Implementing Serializable is entirely optional.	Must implement java.io.Serializable.
  Lifecycle Management	Manually created by the developer using the new keyword.	Manually created by the developer or via reflection by visual design tools.

• Language-Level Design vs. Tooling: Features like annotation-driven boilerplate reduction (Lombok) are handled at the compiler-plugin level by third-party libraries. The Java language designers prefer to keep the core language specifications explicit, readable without special IDE plugins, and structurally sound, rather than turning Java into a kitchen-sink language laden with annotations that rewrite class behavior behind the scenes.

What are Records for#

TIP

Whenever we need a simple, transparent, immutable aggregation of values where behavior is secondary to data carriage, Records are vastly superior to mutable beans, generic POJOs, or enums.

1. Scenario 1: Spring Boot Configuration Object

   We have a spring book application and we need to store the configurations read from application.properties yaml so that we can access those configs programmatically. This configuration object is best to be modeled using Record over Enum or POJO or Bean

   Spring Boot configuration properties (read from application.properties or application.yml) are meant to be immutable data carriers. Once the application boots up and binds those configuration values, they should never change while the application is running.

   If we used a traditional JavaBean, we would have to define private fields, a public no-arg constructor, and mutable setter methods (setHost(), setPort()). This would leave our configuration object in a vulnerable, half-baked state while Spring binds the values, and allow any part of our code to mutate the configuration later. With a record, Spring’s binder populates the values directly into the constructor, and the resulting config object is fully immutable, thread-safe, and clean of setter boilerplate.

2. Scenario 2: Web Service Response Object

   We have a Response object that is returned from all the endpoints of a Java webservice for the similar reason.

   An API response object (like ApiResponse<T>) is a classic aggregation of values sent back to a client. It carries data from the service layer to the transport layer without containing complex business logic or extensible behavior.

   Response payloads need to be transparent, predictable, and immutable so that data integrity is guaranteed as it leaves our system. Records automatically generate equals(), hashCode(), and toString(), making them exceptionally easy to log, serialize to JSON, and assert against in unit tests.

Other scenarios where Java Records shine include

• Data Transfer Objects (DTOs) between microservices or layers
• Multi-field composite keys or map keys (a composite map key consisting of multiple distinct values)
• Event messages between publishers and consumers (e.g., Kafka or RabbitMQ)

TIP

Want to harness this insight into your Java development? Start coding with OpenML Vertex agent now~

Simple Recency & Order-Based Algorithms#

These are the most basic algorithms, focusing on the order or time of access.

• Least Recently Used (LRU): This is one of the most popular algorithms. It evicts the item that has not been used for the longest time. It’s based on the idea of temporal locality: if we used something recently, we are likely to use it again soon.
• First-In, First-Out (FIFO): The first item added to the cache is the first one to be evicted, regardless of how often or recently it was used. It’s simple to implement but often inefficient, as it can evict popular items that were just loaded early.
• Most Recently Used (MRU): This algorithm evicts the item that was most recently used. This seems counter-intuitive, but it’s effective in specific cases, such as database full-table scans, where the data is read once and is unlikely to be needed again soon.
• Random Replacement (RR): As the name suggests, it just picks an item at random to evict. It’s very simple and avoids the overhead of tracking access, but its performance is unpredictable.

Frequency-Based Algorithms#

These algorithms track how many times an item is accessed.

• Least Frequently Used (LFU): This algorithm evicts the item that has been accessed the fewest times. The idea is to keep the most popular items. LFU, however, struggles with cache pollution. An item that was popular in the past but is no longer needed can “pollute” the cache and never get evicted, while a new, instantly popular item might be evicted before its frequency count can build up.

Advanced & Adaptive Algorithms#

These are more complex, high-performance algorithms that solve the problems of the simpler ones. They are often “scan-resistant,” meaning a single pass over a large dataset (like a backup or index) won’t wipe out all the useful, popular data in the cache.

1. Adaptive Replacement Cache (ARC) is a high-performance algorithm that constantly balances between LRU (recency) and LFU (frequency). It’s considered one of the best general-purpose algorithms.
2. 2Q (Two-Queue) is a simpler algorithm that also solves the scan-resistance problem.
3. SIEVE is an algorithm that has gained significant attention for being simpler than LRU but higher-performing than many complex algorithms.