DEV Community: Vipin Sharma

Avoid multi threading bugs using immutable Java Records

Vipin Sharma — Sun, 13 Jun 2021 12:40:57 +0000

In a multi-threaded Java application, any thread can change the state of an object. Java memory model in Java language specification specifies when exactly updates made by one thread are going to be visible to other threads. This is one of the biggest problems professional java developers deal with every day. Java records are immutable, an object is considered immutable if its state cannot change after it is constructed. The immutable nature of the record eliminates problems of its usages in a multithreaded environment.

Previous blog post on record explains how record provides a way to create data carrier-classes without writing a lot of boilerplate code. As part of this post, we will focus on the immutable feature of the record. Immutability is one of the best features provided by records, we can use a record object without worrying about other threads changing its state.

Java language features making record immutable

In this section, we will go through a table explaining how records are made immutable in the Java language. In the below table the 2nd column explains different ways to update the state of a record object, the 3rd column explains Java language features that prevent updating the state of the Record object.

Index	Way to update record	Java language features preventing it
1	Create a record sub-class and change the state of the sub-class.	Record classes are implicitly final and can not be abstract, this way we can not create a sub-class of the record class.
2	Extend some other class(superclass) and change the state of the superclass.	All record classes extend java.lang.Record by default so can not extend any other class.
3	Add instance fields that can be modified.	Record classes cannot declare instance fields.
4	Update record components.	We can not assign a new value to record components as these are implicitly final. These are assigned values while initializing the record in a canonical constructor.
5	Update record components in the constructor.	Only canonical constructor can update record components, which is called while initializing record. For other types of constructors, assigning any of the record components in the constructor body results in a compile-time error.
6	Update record components using reflection.	Record components have specific handling in Reflection *Field API. This treatment is like hidden classes. You can read more about Hidden classes here*.

Shallowly immutable

Record components are final, which means we can not change the record components once assigned. Although we can change fields of the record component, there is no restriction on that, it makes the record shallowly immutable. Let's see this with an example.

public class EmployeeTest {

    public static void main(String[] args) {
        List<Integer> integerList = new ArrayList<>();
        integerList.add(1);
        IntegerListRecord integerListRecord = new IntegerListRecord(integerList);

        System.out.println(integerListRecord.getListSize());

        integerList.add(2);
        System.out.println(integerListRecord.getListSize());
    }
}

    record IntegerListRecord(List<Integer> integerList) {
        int getListSize()
        {
            return integerList.size();
        }
    }

In this example, we created a list of integers(integerList), added one element into it, and initialized the record class with this. Calling method getListSize of record class results into 1. Now we add one more element in integerList and calling getListSize results into 2. Here we did not change the record component (integerList) but updated the fields of the record component, which does not have any restriction. This is the reason we call the record shallowly immutable.

Conclusion

Records help you remove repetitive and error-prone code, and increases developer productivity. The immutability feature keeps it away from concurrency bugs. Using language features like this is going to make you a great developer everyone wants to hire.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Resources

Java Records: concise and readable data carrier classes

Vipin Sharma — Fri, 02 Apr 2021 09:56:07 +0000

Records

Professional Java developers need immutable data carrier-classes for communication with databases, web Services. We need to write a lot of boilerplate code to create a simple data carrier-class, we typically implement constructor, accessors, equals(), hashCode(), and toString(). This process is repetitive and error-prone. Developers also complain “Java is too verbose”.

Record classes provide a way to model data in java. An example of data is one row from a database table. This feature simplifies coding, makes java code more concise and readable. It is going to increase productivity for professional java developers. Java14 introduced Records as a preview feature, Java15 brings in some updates as a second preview and Java16 makes it a final feature, no changes in Record after this.

Common implementation use cases

1. Multiple return values: Often we encounter cases when we want to return multiple values from a method, for this we will have to create a class having values that we need to return. The record provides an easy way rather than writing boilerplate code.

2. Data transfer objects (DTO): Developers working with databases often write DTO which is typically used for storage only, we can again reduce boilerplate code using java Record classes.

Java code before and after Record

Following is one example showing Point class without using record.

class Point
{
 public final int x;   
 public final int y;    
 public Point(int x, int y) { this.x = x; this.y = y; }    
 public int getX() {...}   
 public int getY() {...}   
 public String toString() {...}   
 public boolean equals(Object o) {...}   
 public int hashCode() {...)  
}

Record equivalent for Point class is following one line, WOW !

record Point(int x, int y){}

In this example record class name is Point, and it has 2 components x,y that describes state. The record class can have a body as well, later in this post we have such examples.

We can use javap command to see the compiled class:

javac com/jfeatures/jdk16/records/Point.java 
javap -p com/jfeatures/jdk16/records/Point.class

Compiled from "Point.java"
final class com.jfeatures.jdk16.records.Point extends java.lang.Record {
  private final int x;
  private final int y;
  com.jfeatures.jdk16.records.Point(int, int);
  public final java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public int x();
  public int y();
}

In the above output of the javap command we can see the record classes have:

A private final field for each component in record declaration(state description). (In the above example private final int x, private final int y)
A public read accessor method for each component of the Record, with the same name and type as the parameter. (public int x(), public int y())
A public constructor, having the same arguments as the components of the record, is also called a canonical constructor. This constructor initializes each field from the corresponding argument. (com.jfeatures.jdk16.records.Point(int, int))
Implementations of equals and hashCode that say two record classes are equal if they are of the same type and contain the same state.
An implementation of toString that includes the string representation of all the record components, with their names.

Record classes in detail

Record classes behave like normal classes except restrictions, following are few properties of the Record classes:

Can be declared as top-level or nested, can be generic.
Can implement interfaces.
Are instantiated via the new keyword.
Record class body may declare static methods, static fields, static initializers, constructors, instance methods, and nested types.
The record class and the individual components in a state description, can be annotated.
We can define a nested record class. Nested record is implicitly static, because an immediately enclosing instance can add a state to the record.
Instances of record classes can be serialized and deserialized. Serialization is done using Record components and deserialization is done using the canonical constructor. Serialization and deserialization can not be customized via regular means (writeObject, readObject, readObjectNoData, writeExternal, or readExternal methods).

Restrictions on record

Following code shows compilation error in extends, because Record classes are implicitly final.

record Base(int a) { }
record Child(int a, int b) extends Base { }

Similarly, we have a few more restrictions to follow for record classes.

Restrictions on Record classes can be divided into 3 categories:

Restrictions that ensure the record class components alone defines the representation
1. record classes cannot extend any other class
2. record classes cannot declare instance fields, only record components carry the state of the record object.
Restrictions that emphasize the API of a record is defined solely by its record components, and cannot be enhanced
later by another class or record.
1. record classes are implicitly final.
2. record classes cannot be abstract.
3. record classes cannot declare native methods.
Restriction to make sure record is immutable by default.
1. The components of a record are implicitly final.

Constructors

Record classes have 3 types of constructors:

Canonical constructor
Compact canonical constructor
Custom constructor

Canonical constructor:
It contains all components of the record. This is declared implicitly, can be declared explicitly as well. Starting From Java15, if the canonical constructor is implicitly declared then its access modifier is the same as the record class. If the canonical constructor is explicitly declared then its access modifier must provide at least as much access as the record class.

record Employee(String name, int id) {
       Employee(String name, int id) {
           this.name = name;
           this.id = id;
       }
}

Compact canonical constructor: It doesn't have any parameter, it is always called when defined. The compact form helps developers focus on validating and normalizing parameters. Here parameters are declared implicitly, and the private fields corresponding to record components are automatically assigned (this.x = x) at the end of the constructor.

record Employee(String name, int id) {
        Employee {
            //validation
            if(name.length()==0) throw new RuntimeException("Nota a valid name");
        }
}

For a Record class, only one out of canonical constructor or compact canonical constructor can be defined. Defining both results into compilation failure.

Custom constructor: We can create custom constructors as well having only a few parameters from the Record header. Since this is not a canonical constructor, its first statement must invoke another constructor of the record class.

record Employee(String name, int id) {
       public Employee(String name) {
           this(name, 0);
       }
}

Starting from Java 15 assigning any of the instance fields (record components) in the constructor body became a compile-time error. Only the canonical constructor is allowed to do this.

Update on @override annotation

Java 15 extends the meaning of the @override annotation to include an explicitly declared accessor method for a record. Now following is valid java code.

package com.jfeatures.jdk16.records;

public record Employee(String name, int id) {

    @Override
    public int id() {
        return id;
    }

    @Override
    public String name() {
        return name;
    }
}

Local record, enum, and interfaces are now allowed in Java

Java15 introduced the ability to declare local record classes, local enum classes, and local interfaces. Nested record classes and local record classes are implicitly static. It avoids adding an immediate enclosing instance to the state of the record class.

public class LocalComponents {
    public static void main(String[] args) {
        System.out.println("Start Test");
        new LocalComponents().instanceMethod();
    }

    void instanceMethod() {
        record LocalRecord(int x, int y) {
            LocalRecord {
                System.out.println("Inside Local Record compact canonical constructors");
            }
        }
        enum LocalEnum {
            VALUE1,
            VALUE2;
        }

        interface LocalInterface extends Cloneable {
        }
    }
}

For versions before Java15, above code will not compile. Following is a compilation error for local enum in above example.

com/jfeatures/jdk16/records/LocalComponents.java:16: error: enum types must not be local
enum LocalEnum {
^
1 error

Inner class can declare static members

Before Java 16, an inner class can not declare a static member. Java 16 allows the inner class to declare a member of the type record class. This will allow an inner class to declare a member that is a record class.

package com.jfeatures.jdk16.records;

public class RecordInInnerClass {
    public static void main(String[] args) {
        System.out.println("Starting test");
    }

    class Inner{
        record TestRecord(int id, String name){
        }
    }
}

This code shows below compilation error with Java 15, it works fine with Java16 or later.

javac --enable-preview -source 15 com/jfeatures/jdk16/records/RecordInInnerClass.java
com/jfeatures/jdk16/records/RecordInInnerClass.java:9: error: static declarations not allowed in inner classes
record TestRecord(int id, String name){
^
Note: com/jfeatures/jdk16/records/RecordInInnerClass.java uses preview language features.
Note: Recompile with -Xlint:preview for details.
1 error

Why record, why not just tuples?

A central aspect of Java's philosophy is that "names" matter. A Person with properties firstName and lastName is clearer and safer than a tuple of String and String.

Conclusion

Records help you remove repetitive and error prone code, reduce bugs in your code, reduces verbosity in code, and increases developer productivity. Using language features like this is going to make you a great developer everyone wants to hire.

If you want to get amazing Java jobs, I wrote an ebook 5 steps to Best Java Jobs. You can download this step-by-step guide for free!

Resources

Records: Data Carrier classes in Java 14

Vipin Sharma — Mon, 03 Aug 2020 18:23:03 +0000

Records

This feature is going to increase productivity for professional java developers. It simplifies coding, makes java code more concise and readable. Records provide a way to model data in java, example for data could be one row from the database table.

Common implementation use cases

1. Multiple return values: Often we encounter cases when we want to return multiple values from a method, for this we will have to create a class having values that we need to return. Record provides an easy way rather than writing boilerplate code.

2. Data transfer objects (DTO): Developers working with databases often write DTO which typically used for storage only, we can again reduce boilerplate code using java records.

Java code before and after Record

To write even a simple data carrier class we have to write a lot of boilerplate code. Like constructors, accessors, equals(), hashCode(), toString(), etc.
Following is one example showing Point class without using record.

class Point
{
 public final int x;   
 public final int y;    
 public Point(int x, int y) { this.x = x; this.y = y; }    
 public int getX() {...}   
 public int getY() {...}   
 public String toString() {...}   
 public boolean equals(Object o) {...}   
 public int hashCode() {...)  
}

Record equivalent for Point class is following one line, WOW !

record Point(int x, int y){}

In the above example you can see, the record has a name and a state description. The state description declares the components of the record. and y are here components of the record. The record can have a body as well, we will see this later in examples.

This feature is in preview mode. To use the preview feature we need to pass --enable-preview parameter. Sample command for RecordsJDK14.java is:

javac --enable-preview -source 14 com/vip/jdk14/JavaRecords.java
java --enable-preview com.vip.jdk14.JavaRecords

We can use javap command to see compiled class:

javac  --enable-preview -source 14 Point.java
javap -p Point.class

Compiled from "Point.java"
public final class com.vip.jdk14.Point extends java.lang.Record {
  private final int x;
  private final int y;
  public com.vip.jdk14.Point(int, int);
  public java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public int x();
  public int y();
}

In the above output of the javap command we can see following are properties of Records, Records have:

A private final field for each component in record declaration(state description). (In above example private final int x, private final int y)
A public read accessor method for each component of Record, with the same name and type as the parameter. (public int x(), public int y())
A public constructor, having the same arguments as the components of the record. This constructor initializes each field from the corresponding argument. (public com.vip.jdk14.Point(int, int))
Implementations of equals and hashCode that say two records are equal if they are of the same type and contain the same state.
An implementation of toString that includes the string representation of all the record components, with their names.

Records behave like normal classes except restrictions, following are few properties of the Records:

They can be declared top level or nested, they can be generic.
They can implement interfaces.
They are instantiated via the new keyword.
The record's body may declare static methods, static fields, static initializers, constructors, instance methods, and nested types.
The record and the individual components in a state description can be annotated.
We can define a nested record, which is implicitly static. It avoids an immediately enclosing instance that would silently add state to the record.

Records have 3 types of constructors we can define explicitly:

Canonical constructor: It contains all components of record.
Compact constructor: It doesn't have any parameter, it is always called when defined.
Custom constructor: All others except above 2.

Following is an example of all 3 types of constructors we talked about.

record NameValue(String name, int value) {
    //canonical constructor (It contains all components of record)
    public NameValue(String name, int value) {
        this.name = name;
        this.value = value;
    }  
    //compact constructor, no parameter, always called when defined.
    public NameValue {
        if(value == 1) throw new RuntimeException(""); //throwing Exception whenever value is 1, this is to test if it is called always.
    }
    // Custom constructor
    public NameValue(int value) {
        this(null, value); // Necessary to avoid compilation error
        if(value == 2) throw new RuntimeException(""); // Throwing Exception to test when is this called.
    }
}

Restrictions on record

Following code throws compilation error in extends, because Records are implicitly final.

record Base(int a) { } 
record Child(int a, int b) extends Base { }

Similarly, we have a few more restrictions to follow for Records.

Restrictions on records can be divided into 3 categories:

Restrictions that ensure the state description alone defines the representation
1. Records cannot extend any other class
2. Records cannot declare instance fields other than the private final fields which correspond to components of the state description. Any other fields which are declared must be static.
Restrictions that emphasize the API of a record is defined solely by its state description, and cannot be enhanced later by another class or record.
1. Records are implicitly final.
2. Records cannot be abstract.
This restriction embodies an immutable by default policy.
1. The components of a record are implicitly final.

Why Record why not just tuples?

A central aspect of Java's philosophy is that "names" matter. A Person with properties firstName and lastName is clearer and safer than a tuple of String and String.

At the end

To learn the best java language features and get the best Java Jobs, download my ebook 5 steps to Best Java Jobs for Free.

Follow me on twitter @vipinbit to get daily tips like this on Java Language Features.

Resources

https://openjdk.java.net/jeps/359
https://cr.openjdk.java.net/~briangoetz/amber/datum.html
https://github.com/Vipin-Sharma/JDK14Examples, this repository has all code we discussed in this post.

Text Blocks: No more errors in Java multi-line Strings

Vipin Sharma — Sat, 01 Aug 2020 01:00:00 +0000

Do you find Java multiline Strings not readable?

Multi-line strings in java are often not readable which makes it error-prone. JDK 15 Standard feature Text blocks provide us a better way to write strings that span several lines of source code.

Let's check the java code example to understand how text blocks make our code more readable and bug-free.

Can you spot a bug in the multiline String below?

String oldMultiLineStringSQL = "select emp_id, emp_name, emp_num_of_kids, emp_active" +
                             "from employee_table" +
                             "where employee_num_of_kids =1";

System.out.println(oldMultiLineStringSQL);

Following is the console output for oldMultiLineStringSQL.

select emp_id, emp_name, emp_num_of_kids, emp_activefrom
employee_tablewhere employee_num_of_kids =1

In this output notice the words in bold, here we don't have spaces between words of consecutive lines. It causes SQLSyntaxErrorException.

Next section we will see how this problem can be solved by Text blocks.

Text Blocks Java code

Now the same code we are writing using Java Text Blocks.

String sqlWithTextBlocks = """
                select emp_id, emp_name, emp_num_of_kids, emp_active      
                from employee_table      
                where employee_num_of_kids =1 
                """;

Following is console output for text blocks, it is the same as we have written in code. No issues due to space among consecutive lines.

select emp_id, emp_name, emp_num_of_kids, emp_active
from employee_table
where employee_num_of_kids =1

The deep dive into Text block syntax

A text block consists of zero or more content characters, enclosed by opening and closing delimiters.

The opening delimiter is a sequence of three double-quote characters (""") followed by zero or more white spaces followed by a line terminator.
The closing delimiter is a sequence of three double-quote characters.
The content begins at the first character after the line terminator of the opening delimiter and ends before the closing delimiter.

Text blocks compile-time processing

The content of a text block is processed by the Java compiler in three steps in the same sequence as given below:

Line terminators: Line terminators in the content are translated to LF (\u000A).
Common white spaces removal: Incidental white space surrounding the content, introduced to match the indentation of Java source code is removed in this step.
Escape sequence processing: Escape sequences in the content are interpreted in this step. Performing interpretation as the final step means developers can write escape sequences such as \n without them being modified or deleted by earlier steps.

The following sections have all 3 steps of compile-time processing in more detail.

Line terminators

Different operating systems have their Line terminators.
All line terminators (CR/LF/CRLF) in the content are translated into LF (\u000A).
It makes the same java code work across all platforms.

White space removal

Following two rules help us understand whitespace removal.

There has to be one line terminator immediately after the initial opening delimiter.
Now we have content and closing delimiter. if we move any line of content or closing delimiter to left it reduces common whitespace prefix. In other words, left most character in content or end delimiter decides the starting character of all lines in the text block.

Let's check some examples to understand how it works in practice.

In all the examples

dots (.) are used to show spaces in code.
Vertical bars (|) are used to visualize the left margin.

This is the first example having no whitespaces in the output.

public static void printTextBlock() {
....String textBlock = """
............First line of test block
............Second line of test block
............""";
....System.out.println(textBlock);
}

Following is the Intellij idea screenshot for the above code.

Following is the output, showing all incidental white spaces removed.

|First line of test block
|Second line of test block
|

This is the second example showing initial character position in the text block is decided by the start of the second line in text block content, out of all lines of content and end delimiter here, the second line has leftmost character.

public static void printInitialCharacterPositionDecidedByLeftMostCharacterOfLines() {
....String textBlock = """
............First line of test block
........Second line of test block
............""";
....System.out.println(textBlock);
}

Following is the Intellij idea screenshot for the above code.

Following is the output of the second example. We can see the initial 4 spaces that are common are removed in output.

|    First line of test block
|Second line of test block
|

This is the third example showing the effect of moving the end delimiter to left.

public static void printInitialCharacterPositionDecidedByEndDelimiter() {
....String textBlock = """
............First line of test block........
............Second line of test block........
........""";
....System.out.println(textBlock);
}

Following is the Intellij idea screenshot for the above code.

In the following output of the third example. We can see spaces at the end of the line are removed. Moving the end delimiter 4 spaces to left adds 4 spaces in all the lines.

|    First line of test block
|    Second line of test block
|

This is the fourth example showing the effect of moving the end delimiter to right. Here we see moving the end delimiter to the right of content has no effect.

public static void printTextBlockMovingEndDelimiterToRightOfContentHasNoEffect()
{
....String textBlock = """
............First line of test block         
............Second line of test block      
................""";
....System.out.println(textBlock);
}

Following is the Intellij idea screenshot for the above code.

Following is the output of the fourth example, it shows no effect of moving the end delimiter to left, all common white spaces are removed.

|First line of test block
|Second line of test block
|

In all these examples you can see the green vertical bar in the IntelliJ idea shows the starting character of lines in the text block.

Escape processing

This is the third and last step of compile-time processing. We have seen first line terminators are interpreted, then the next step is white space removal and at the end escape processing. And because this is the last step in compile-time processing when we use \n (or any other escape sequence) in text block content, it will not be modified by the initial 2 steps and will be interpreted at the end.

Let's learn different language features in escape processing using the below code example.

private static void printEscapeProcessing() {
....String textBlock = """
............"Hello\n
............Text Block " ' \\ \t "
............experiment another opening/closing delimiter type of 3 consecutive quotes \"""
............without newline concatenation of Strings \
............spaces \s\sat end in this way trailing spaces are not removed\s\s
............\"""";
....System.out.println("printEscapeProcessing");
....System.out.println(textBlock);
}

Following is the output of the above escape processing example.

|printEscapeProcessing
|"Hello
|
|Text Block " ' \   "
|experiment another opening/closing delimiter type of 3 consecutive quotes """
|without newline concatenation of Strings spaces ..at end in this way trailing spaces are not removed..  
|"

In the above output few things to observe are:

\n is allowed in the text block, and it generates an additional new line in the output.
" and ' can be used anywhere in text blocks like Strings.
to use \ we need to use \\.
Sequences of three double quotes """ characters require the escaping of at least one " to avoid mimicking the closing delimiter.
To allow finer control of the processing of the newlines and white space, two new escape sequences are introduced in java 15, these were not present in earlier preview versions.
1. \ at the end acts like a concatenation of 2 Strings, in other words, it avoids line terminator between consecutive lines.
2. \s adds space, in example output spaces are shown with dots (.)

Common mistakes in text blocks

Here are some examples of ill-formed text blocks:

String a = """""";   // no line terminator after opening delimiter
String b = """ """;  // no line terminator after opening delimiter
String c = """
           ";        // no closing delimiter
String d = """
           abc \ def
           """;      // unescaped backslashs

At the end

Knowing language features like this helps you get the best java jobs, that's why to help you I wrote the ebook 5 steps to Best Java Jobs.
Download this step by step guide for free!

Resources

https://openjdk.java.net/jeps/378, This is the Java enhancement proposal for text blocks in JDK15.
https://github.com/Vipin-Sharma/JDK15Examples, this is the link to code examples used in this post.

Can NullPointerException be helpful?

Vipin Sharma — Wed, 08 Jul 2020 04:07:31 +0000

Have you ever received NullPointerException ?

Every Java developer has encountered NullPointerExceptions, this is most common programming error new Java Developers face.

Following is one simple programming mistake, I am trying to call method size on null list.

public class NullPointerExceptionDemo {
    public static void main(String[] args) {
        List<Integer> list = null;
        System.out.println(list.size());
    }
}

This is output of running NullPointerExceptionDemo

Exception in thread "main" java.lang.NullPointerException
at com.vip.jdk14.NullPointerExceptionDemo.main(NullPointerExceptionDemo.java:8)

Process finished with exit code 1

In above example it is clear list is null but several other situation it is not easy to understand root cause. See following example.

    System.out.println(objectA.getObjectB().getObjectC().getObjectD());

Here you may get NullPointerException, when objectA or objectA.getObjectB() or objectA.getObjectB().getObjectC() any of them is null. And you get same NullPointerException message in all these cases.

Java 14 can show you root cause of NullPointerException

Now Java 14 has added language feature to show root cause of NullPointerException.
This language feature has been part of SAP commercial JVM since 2006.

Helpful NullPointerException

In Java 14 you can start passing -XX:+ShowCodeDetailsInExceptionMessages in VM arguments and it helps you to see root cause of NullPointerException.
In Java 14 option is disabled by default and in later releases this will be enabled by default.

public class HelpfulNullPointerExceptionDemo {
    public static void main(String[] args) {
        List<Integer> list = null;
        System.out.println(list.size());
    }
}

Running this program prints following Exception message, and root cause is clearly written list is null.

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because "list" is null
at com.vip.jdk14.HelpfulNullPointerExceptionDemo.main(HelpfulNullPointerExceptionDemo.java:8)

Process finished with exit code 1

At the end

To learn the best java language features and get the best Java Jobs, download my ebook 5 steps to Best Java Jobs for Free.

Follow me on twitter @vipinbit to get daily tips like this on Java Language Features.