Java Records Are Here - Available in JDK 14

We need justification not to use immutable objects in ours solutions, rather than an affirmative reason to use them.

Records provide a first-class means for modeling data-only aggregates. They are available in Java since release of JDK 14.

Records are often seen as syntactic sugar to easily create immutable objects without having to write a lot of boilerplate code. And records as a clean definition of immutable objects can have a tremendous impact on your component design.

You as a designer have to reflect why your abstractions are not immutable and what is the rational behind. From experience it improves greatly the quality of your design.


Records guarantee

• An immutable class concept which is the strongest argument for the use of record,
• Cannot change their state after construction,
• Don’t change the state of the whole system in any way,
• Don’t do side effects, like inputs and outputs for example,

Records provide

• A set of boilerplate methods generated by the Java ecosystem. These methods are always semantically correct and efficient,
• A public constructor initializing all instance variables
• Getters for all instance variables. The name of the getters is PropertyType property(). Finally we get rid of the cumbersome and outdated convention PropertyType getProperty() propagated by Java Beans.
• A semantic correct implementation of hashCode() and equals(). Therefore your objects can be used in standard API collections without difficult to find bugs.
• An human readable implementation toString()

The huge advantage of the approach against IDE code generation is the guaranty that these methods are semantically always correct.

Advantages

Some of the key benefits of immutable objects are:

• Thread safety
• Atomicity of failure
• Absence of hidden side-effects
• Protection against null reference errors
• Ease of caching
• Prevention of identity mutation - see contract for API standard collections -
• Avoidance of temporal coupling between methods
• Support for referential transparency
• Protection from instantiating logically-invalid objects
• Protection from inadvertent corruption of existing objects

Design Impact

I updated my open source projects to use the record abstraction. What a surprise! I found regularly undocumented trade-offs why a class was not implemented as an immutable type. Quite often I was just lazy and took a shortcut.

Records motivate you as a clean coder and designer to decide why a class should be mutable or not. This pressure had a tremendous impact on the quality of my subsystem design. The Java language guarantees that all record classes must be immutable.

And immutable value objects are a cornerstone in the Domain Driven Design DDD approach.

If you are using Data Transfer Objects DTO they should probably always be records. In the long run you should eliminate your DTO, they are just waste and break all the rules of abstraction and information hiding.

Tricks and Tips

You can define a constructor extension to validate the passed arguments. This validation block is automatically inserted at the beginning of the generated constructor.

 record Range(int lo, int hi) {  
  public Range {  
   if (lo > hi) /* referring here to the implicit constructor parameters */  
    throw new IllegalArgumentException(String.format("(%d,%d)", lo, hi));  
  }  
 }  

As soon as the record has more than a few instance variables calling the constructor with various set of default values can become cumbersome.

Two approaches easily mitigate this problem.

• For simple situation create static factory methods taking care of default parameter values. For examples look at the standard API List class and the set of static of methods.
• For more complex situation implement the builder patten to provide full flexibility to the consumers of your class.

Start using the new concept of record in your source code and implicitly improve the quality of your design. At the same time write less boilerplate code and enjoy coding.