DEV Community: Ashish Garg

Records in JDK16 (JEP 395)

Ashish Garg — Sat, 29 Feb 2020 14:50:11 +0000

Overview

JEP 359 (Records) added as preview feature in JDK 14 and stable production ready feature with JEP 395 in
JDK 16. Records are part of larger release named as project
Amber (Umbrella project having multiple feature
targeted in various releases).

Records are primarily designed to target the use-case where classes are getting created, just to
hold data (DTOs). Usually in beginning developer create a data aggregate class with the pure
intention to hold data but during course of project it got corrupted with various business logic
(functional methods) and lost its flavour of pure data aggregate and become a nightmare to manage.
You might be thinking of using Record in place of JPA Entities, why it's not possible I will
explain later.

Let’s say in today’s world developer like to create a data aggregate class, he/she will create
something like below with required fields. I have created a Fund class with some fields like
nameOfFund, IdOfFund etc.

public class Fund {

    private String nameOfFund;
    private String IdOfFund;
    private FundType typeOfFund;
    private float unitOfPrice;
    private String nameOfFundManager;
    private float exitLoad;
    private float aum;
    private boolean lockIn;
}

enum FundType{
    LARGE_CAP,
    MID_CAP,
    SMALL_CAP,
    MULTI_CAP,
    HYBRID
}

As you might have noticed, this is a simple class with different fields representing state of
class but for a developer who will read it later there is no explicit communication from language
semantics that this is a data aggregate not a Java Bean, also it does not have certain required
methods i.e. equals(), hashCode(), toString(), Constructors and Getters to make it useful.

Writing all these methods introduce a lot of boilerplate code for a developer to write, even most
of the IDEs in today’s world can generate these methods still it’s a brain exercise for developer
who has to read it and there is always a possibility at some day developer will add/remove
certain fields from it but did he rightly update all relevant method (equals & hashCode) will
always be question?

Let’s see how a Fund class will look like after all required methods generated by our
favourite IDE (I have used IntelliJ Community Edition to generate these methods)

public class Fund {

    private String nameOfFund;
    private String IdOfFund;
    private FundType typeOfFund;
    private float unitOfPrice;
    private String nameOfFundManager;
    private float exitLoad;
    private float aum;
    private boolean lockIn;

    public Fund(String nameOfFund, String idOfFund, FundType typeOfFund, float unitOfPrice, String nameOfFundManager, float exitLoad, float aum, boolean lockIn) {
        this.nameOfFund = nameOfFund;
        IdOfFund = idOfFund;
        this.typeOfFund = typeOfFund;
        this.unitOfPrice = unitOfPrice;
        this.nameOfFundManager = nameOfFundManager;
        this.exitLoad = exitLoad;
        this.aum = aum;
        this.lockIn = lockIn;
    }

    public String getNameOfFund() {
        return nameOfFund;
    }

    public void setNameOfFund(String nameOfFund) {
        this.nameOfFund = nameOfFund;
    }

    public String getIdOfFund() {
        return IdOfFund;
    }

    public void setIdOfFund(String idOfFund) {
        IdOfFund = idOfFund;
    }

    public FundType getTypeOfFund() {
        return typeOfFund;
    }

    public void setTypeOfFund(FundType typeOfFund) {
        this.typeOfFund = typeOfFund;
    }

    public float getUnitOfPrice() {
        return unitOfPrice;
    }

    public void setUnitOfPrice(float unitOfPrice) {
        this.unitOfPrice = unitOfPrice;
    }

    public String getNameOfFundManager() {
        return nameOfFundManager;
    }

    public void setNameOfFundManager(String nameOfFundManager) {
        this.nameOfFundManager = nameOfFundManager;
    }

    public float getExitLoad() {
        return exitLoad;
    }

    public void setExitLoad(float exitLoad) {
        this.exitLoad = exitLoad;
    }

    public float getAum() {
        return aum;
    }

    public void setAum(float aum) {
        this.aum = aum;
    }

    public boolean isLockIn() {
        return lockIn;
    }

    public void setLockIn(boolean lockIn) {
        this.lockIn = lockIn;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Fund)) return false;
        Fund fund = (Fund) o;
        return Float.compare(fund.unitOfPrice, unitOfPrice) == 0 &&
                Float.compare(fund.exitLoad, exitLoad) == 0 &&
                Float.compare(fund.aum, aum) == 0 &&
                lockIn == fund.lockIn &&
                nameOfFund.equals(fund.nameOfFund) &&
                IdOfFund.equals(fund.IdOfFund) &&
                typeOfFund == fund.typeOfFund &&
                nameOfFundManager.equals(fund.nameOfFundManager);
    }

    @Override
    public int hashCode() {
        return Objects.hash(nameOfFund, IdOfFund, typeOfFund, unitOfPrice, nameOfFundManager, exitLoad, aum, lockIn);
    }

    @Override
    public String toString() {
        return "Fund{" +
                "nameOfFund='" + nameOfFund + '\'' +
                ", IdOfFund='" + IdOfFund + '\'' +
                ", typeOfFund=" + typeOfFund +
                ", unitOfPrice=" + unitOfPrice +
                ", nameOfFundManager='" + nameOfFundManager + '\'' +
                ", exitLoad=" + exitLoad +
                ", aum=" + aum +
                ", lockIn=" + lockIn +
                '}';
    }
}

enum FundType{
    LARGE_CAP,
    MID_CAP,
    SMALL_CAP,
    MULTI_CAP,
    HYBRID
}

Record

To address such concerns JEP 359 comes with a new type declaration record like enum we
already have. Records as name specify is purely mean for having/holding data without any
functionality. It also helps to reduce a lot of boilerplate code which developer need to write
to create a data aggregate. In today’s world there is no mean to communicate that developer
created a class with the pure intention of data aggregate, record will make this communication very
crystal clear.

record Fund(String nameOfFund, String idOfFund, FundType typeOfFund, float unitPrice, String nameOfFundManager,
        float exitLoad, float aum, boolean lockIn) {}

In above code snippet record type has been specified just before name and required fields
has been placed with their type under braces () that’s all you need to do as a developer to create
data aggregate. Record comply with the property of immutable class.

As mentioned in effective java also “Classes should be immutable unless there’s a very good
reason to make them mutable.If a class cannot be made immutable, limit its mutability as much
as possible” Generally to make an immutable class developer need to make sure:

Class must not be extendable — make the class final, or use static factories and keep constructors private
Make fields private final
Do not any declare any method which can change state of object after creation

As definition a record class declaration consists of a name, optional type parameters, a header,
and a body. The header lists the components of the record class, which are the variables that
make up its state. In case of record Compiler will create an Immutable class based on record header declaration
with below features:

For each component in header there will be a private final field and Getter for each component with the same name and type as specified in state
A canonical constructor with the same name as record and having all fields with type
Implementation of equals() and hashCode()
Implementation of toString()

If you want to see what all methods have been created by compiler simply run javap on *.class file (Compilation instructions has been provided at the end of this article)

In above snapshot your can see record class is final and extending java.lang.Record

Rules for Constructor

A normal class without any explicit constructor declaration got default constructor from java compiler that's not true for record; record class without any constructor declarations is automatically given a canonical constructor that assigns all the private fields to the corresponding arguments.
Canonical constructor may be declared explicitly with a list of formal parameters which match the record header.
There is another form of constructor defined in Record named as Compact canonical constructor the parameters are declared implicitly, and the private fields corresponding to record components cannot be assigned in the body but are automatically assigned to the corresponding formal parameter (this.x = x;) at the end of the constructor. The compact form helps developers focus on validating and normalizing parameters without the tedious work of assigning parameters to fields.
A record class can be declared top level or nested, and can be generic.
A record class can declare static methods, fields, and initializers.
A record class can declare instance methods.
A record class can implement interfaces and declare instance methods to implement them.
A record class can declare nested types, including nested record classes. If a record class is itself nested, then it is implicitly static; this avoids an immediately enclosing instance which would silently add state to the record class.
Instances of record classes can be serialized and deserialized. However, the process cannot be customized by providing writeObject, readObject, readObjectNoData, writeExternal, or readExternal methods. The components of a record class govern serialization, while the canonical constructor of a record class governs deserialization.

Restriction on Records

Record class cannot extend any other class. The superclass of your record class will always be java.lang.Record, even though a normal class can explicitly extend and there implicit superclass is java.lang.Object.
Records cannot declare instance field and cannot contain instance initializers.
Records are implicitly final and cannot be abstract
Records are immutable as all state components are final.
Any explicit declaration of member must match the type of the automatically derived member.
Any explicit implementation of accessors or the equals or hashCode methods should be careful to preserve the semantic invariants of the record class
A record class cannot declare native methods. If a record class could declare a native method then the behavior of the record class would by definition depend on external state rather than the record class's explicit state.

Local Record classes

Local records are implicitly static this is in contrast of local classes which are not implicitly static.

Reflection

Two new methods has been added in reflection API for records.

getRecordComponents() — Returns an array of **RecordComonent** (This is a new class added in JDK representing a record component) objects representing all the record components of this record class, or **null** if this class is not a record class. Components will be return in the same order as declared while creating record. After getting array of RecordComponent you can iterate individual element and access name, type etc.
isRecords() — Returns true if and only if this class is a record class.

As applicable with developer created Immutable class you can change value of a particular filed via reflection.

Field fld = null;
try {
    fld = fund.getClass().getDeclaredField("aum");
    fld.setAccessible(true);
    fld.setFloat(fund,120f);
    System.out.println(fund.aum);
} catch (NoSuchFieldException | IllegalAccessException e) {
    e.printStackTrace();
}

As shown in above sample, you just need to call setAccessible(true) to update record state. In my opinion as Java added a new type, it shouldn’t allow record state to be change via reflection but that’s my personal opinion JDK designer must be some better reason to allow it.

Serialization

Record support Serialization but there are certain changes has been done in JDK.

Record components/fields are deserialized prior to the invocation of record constructor.
For normal class while serialize/deserialize we can override certain methods (writeObject, readObject etc.) to specify custom behaviour. Its not allowed in record.
The serialVersionUID of a record class is 0L unless explicitly declared
While deserialization system did not match value of serialVersionUID.

Record with Sealed classes

Record work pretty well with upcoming feature Sealed classes (It's under preview right now).

    sealed interface MutualFund permits LargeCap,MidCap,SmallCap {}
        record LargeCap(double AUM) implements MutualFund{}
        record MidCap(double AUM) implements MutualFund{}
        record SmallCap(double AUM) implements MutualFund{}

Important Points

As compiler will create getter method with the same name as field, developer need to conscious enough to provide a good context specific readable name.
Record body may declare static methods, static fields, static initializers, constructors, instance methods, and nested types.
There is very important difference between a class and record.

A class can have field ‘name’, constructor can have an argument ‘name’ and a getter method can have name; all three exist without any relationship but in case of record all three will be referring to same component/field. Here is sample class where there is no relationship between instance field ‘name’, constructor argument ‘name’ and method ‘getname()’.

public class Sample {

    private static String name = "Fun";

    Sample(){
    }

    Sample(String name){
        System.out.println(name);
    }

    private String getname(){
        return "Ashish";
    }

    public static void main(String[] args) {
        System.out.println(name);
        System.out.println(new Sample().getname());
        new Sample("Dummy");
    }
}

if you run above program you will see a output where three different values are getting print on console.

You can’t create a subclass of java.lang.Record, any such attempt will throw error **“records cannot directly extend Record”**.
As mentioned above compiler will create a canonical constructor for you based on the definition provided in record header but there may be case where you like to put kind of validation it has been allowed

public Fund{
    if (nameOfFund==null || idOfFund==null){  
        throw new IllegalArgumentException("Custom exception");
    }
}

Record should be used where you are missing struct in Java.
Record will remove the need of libraries like Lombok.
Record and Inline classes (part of project Valhalla) are two very different things.

Switch Expression (JEP 361)

Ashish Garg — Sat, 29 Feb 2020 06:17:28 +0000

Java has switch statement from very first release candidate. Existing implementation of Switch follows the design and syntax of procedural languages (C and C++) and supports fall through semantics by default.

A typical implementation of switch looks like below:

private static int existingSwitchWithDefault(DAY day){
    int numberOfCharacters = 0;
    switch(day){
        case MONDAY:
        case FRIDAY:
            numberOfCharacters = 6;
            break;
        case TUESDAY:
            numberOfCharacters = 7;
            break;
        case WEDNESDAY:
            numberOfCharacters = 9;
            break;
        case THURSDAY:
        case Saturday:
            numberOfCharacters = 8;
            break;
        default:
            throw new IllegalArgumentException("Invalid input "+day+" provided.");
    }
    return  numberOfCharacters;
}

Some problem with existing switch statement:

Default fall through

Like in other procedural languages default fall through is supported by switch statement. It’s a double edge sword, sometime useful but often dangerous and a nasty place for bug to hide.

In above example, if developer miss to put **break** and write code like this

private static int existingSwitchWithBug(DAY day){
    int numberOfCharacters = 0;
    switch(day){
        case WEDNESDAY:
            numberOfCharacters = 9; // Missed a break FALL THROUGH
        case THURSDAY:
            numberOfCharacters = 8;
            break;
    }
    return  numberOfCharacters;
}

and method will be called like “**existingSwitchWithBug(DAY.WEDNESDAY)”** it will return 8 rather 9, because of Fall Through. Such kind of bugs not easy to find without proper unit test in place.

default is not

Having a default case is not mandatory in existing switch statement, if developer call above method like “**existingSwitchWithBug(DAY.MONDAY)**” it will simply return 0. This can be a valid business case but most of time this happened because developer forget to cover all required cases in switch statement.

Does it not nice if compiler make it mandatory to have a default case in switch statement?

Too verbose

Having break statement after every case make switch statement quite verbose to read and definitely a place to hide errors.

What is Switch Expression?

Switch expression was released as a preview feature in JDK 12 with JEP 325 (in this JEP **break** was overloaded to return a result from switch expression) based on feedback from community (developer find it confusing to use break to return from switch expression), new JEP 325 (new statement yield introduced to return and restored the original meaning of break) was introduced which implemented and released as preview feature with JDK 13.

Switch expression released as standard feature with JDK 14.

Before moving ahead its important to understand the difference between statement and expression. An expression evaluates to a value (you can print it or assign to a variable) and a statement does something, represents an action or command (if else or loops)

If you remember the switch statement example mentioned above same can be written with switch expression like below:

private static int withSwitchExpression(String day){
    int result = switch (day){
        case "Monday","Friday" -> 6;
        case "Tuesday" ->7;
        case "Wednesday" ->9;
        case "Thursday" ->8;
        default -> throw new IllegalStateException("Unexpected value: " + day);
    };
    return result;
}

Couple of things to note in above snippet:

A new form of switch label, “case L ->”, to signify that only the code to the right of the label is to be executed if the label is matched. Code at right of “case L ->” could only be expression, block or throw statement.
If a label is matched, then only the expression or statement to the right of the arrow is executed; there is no fall through.
Switch statement are extended so they can be used as expression, please remember the difference mentioned above between statement and expression.
In case of switch expression a default case is required to emphasize that all possible cases are considered, default case can be skipped if you are using Enum as case identifier, compiler can see if all cases are covered or not

Below code is perfectly fine there will not be any compile time error

switch(day){
    case MONDAY,FRIDAY,SUNDAY -> 6;
    case TUESDAY -> 7;
    case WEDNESDAY -> 9;
    case THURSDAY,SATURDAY -> 8;
};

yield

Till now we have seen example where switch expression case has only single line of code, how about if you have need to write a block something like below:

private static int switchWithBlock(String day){
    int numOfDays = switch (day){
        case "Monday","Friday" -> 6;
        case "Tuesday" ->7;
        case "Wednesday" ->9;
        case "Thursday" ->8;
        default ->{
            int len = day.length();
            yield len;
        }
    };
    return numOfDays;
}

and if you are calling above method with code like “**switchWithBlock(“bizzare”)**”, method will return 7 from default case. Here you must notice yield, it represents a statement to yield a value.

A switch statement, but not a switch expression, can be the target of a break statement. Conversely, a switch expression, but not a switch statement, can be the target of a yield statement.

### Scope of local variable

In switch statement if you declare a local variable under a case it will be accessible to other cases also (local variable visibility also works as fall through only), see below code

switch (day){
    case MONDAY:
        int expense = 50;
        System.out.println("Monday expense is " + 50);
        break;
    case TUESDAY: {
        expense = 90;
        break;
    }
}

here variable “expense” is available for TUESDAY case also even it was declared in MONDAY case.

if you want to stop this behaviour, where a variable declared in particular case block will not be available in another like in above example, you have to write code like this with switch statement

switch (day){
    case MONDAY: {
        int expense = 50;
        System.out.println("Monday expense is " + expense);
        break;
    }
    case TUESDAY: {
        int expense = 90;
        System.out.println("Tuesday expense is " +expense);
        break;
    }
}

here variable “expense” declared and use in particular case only.

Let’s see now how local variable works with switch expression, see below snippet:

switch (day){
    case MONDAY ->{
        int expense = 50;
        System.out.println("Monday expense is "+expense);
    }
    case TUESDAY ->{
        int expense = 60;
        System.out.println("Monday expense is "+expense);
    }
}

as switch expression only allows expression, block and throw in above case is represented as block which limit the local variable scope.

Note:- Both switch statement and switch expression are valid options with JDK 14 and beyond.

instanceof (Pattern Matching) JEP 305

Ashish Garg — Wed, 26 Feb 2020 13:44:13 +0000

Every java developer have written code like below:

if(str instanceof String ){
    int len = ((String)str).length();
}

In above snippet

First a test is happening to confirm ‘str’ is of type String class, if yes
‘str’ is getting cast into a String object, after successful casting
length is getting calculated and assigned to a int.

You must have asked this question why I have to do this casting if I already checked the type before. After successful type check only control will transfer inside if block then ‘str’ can only be String or its subclass there is no other possibility compiler should not asked me to this unnecessary casting.

And there is always a possibility of writing buggy code like this:

if(str instanceof String ){
    int len = ((Integer)str);
}

this will compile just fine by your IDE, and you will be seeing a nice “java.lang.ClassCastException” at runtime.

JEP 305 (Preview in JDK 14)

The instanceof has been extended to support type test pattern. Now you will be coding like this:

if(str instanceof String s){
    System.out.println("length is "+s.length());
}

here instanceof is checking type of ‘str’ as String and assigned it to a binding variable ‘s’. This looks much neat in comparison to older version.

Few important things to keep in mind:

Scope of binding variable

One thing to keep in mind that scope of binding variable is only lies in true statement i.e. in below code block

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

trying to access binding variable ‘s’ in else block will be compile time error “cannot find symbol” as 's' is not visible in else block.

Similarly if you have written a code snippet like below

  private static void newInstanceOfNeg(Object str){
      if(!(str instanceof String s)){
      }else{
          System.out.println(s.length());
      }
  }

‘s’ will be accessible in else block only any attempt to access it in if block will be compile time error.

If name of binding variable matched with another variable in scope of method or class, it can be nasty place for bug to hide. So we need to be very careful about naming them
- Binding variable name in method scope
Observe below snippet, here binding variable named as ‘s’ and method also has another local variable with same name
```
private static void instanceOfFunWithACaveat(Object obj){
    String s = "Ash";
    if(obj instanceof String s){ 
        System.out.println("length is "+s.length());
    }
}
```
good part is, this will not compile and you will be seeing a error like “error: variable s is already defined”.

But if you write something like
```
private static void instanceOfFunWithACaveat(Object obj){
    String s = "Ash";
    if(obj instanceof String str){ 
        System.out.println("length is "+s.length());
    }
}
```
here binding variable named as ‘str’ but under true block code is still referring to method variable ‘s’. It will compile and run perfectly without any error but such kind of typo might turned out to be a bug.
- If binding variable has same name as instance variable
Q- What will happen if binding variable has same name as instance variable and you try to access it in true block, see below snippet ?
```
private static String s = "Ash";
private static void instanceOfFunWithoutElseAndACaveat(Object obj){
    if(obj instanceof String s){
        System.out.println("length is "+s.length());
    }
}   
```
and if you are calling this function with
```
instanceOfFunWithoutElseAndACaveat("Ashish")
```
you will be seeing output as ‘6’ not ‘3’. Binding variable will take precedence here.

Q- What will happen if binding variable has same name as instance variable and you try to access it in false block, see below snippet ?
```
private static String s = "Ash";
private static void instanceOfFunWithElseAndACaveat(Object obj){
    if(obj instanceof String s){
        System.out.println("length is "+s.length());
    }else{
        System.out.println("s is instance variable here"+ s.length());
    }
}
```
and if you are calling this function with
```
instanceOfFunWithElseAndACaveat(1); 
```
you will be seeing output as ‘3’ because in else block instance variable ‘s’ is visible.
- Test pattern with && operator
Usually conditional if block has multiple operator to fulfill certain business need. Let’s take a example where ‘&&’ operator is present along with instanceof test pattern, see below snippet:
```
private static void instanceOfWithAndOperator(Object obj){
    if(obj instanceof String s && s.contains("Ash")){
        System.out.println("In true block");
    }
}
```
here you can see, in if block after instanceof test pattern there is also a contains check separated by ‘&&’ operator. Right side of ‘&&’ will only be execute if instanceof test pattern succeeded.
- Test pattern with || operator
Similar to above, let’s say we have || operator after instanceof test pattern
```
private static void instanceOfWithOrOperator(Object obj){
    if(obj instanceof String s || s.contains("Ash")){
        System.out.println("In true block");
    }
}
```
‘s’ will not be accessible to right side of ‘||’ block neither in if statement nor in else block (if there is instance variable with same name ‘s’ that will be accessible )
- Test pattern with || operator
Let’s say if you are calling below method with null argument
```
private static void newInstanceOf(String str){
    if(str instanceof String s){
        System.out.println("In true block");
    }else{
        System.out.println("In false block");
    }
}
```
it will simply print “In false block”, instanceof test pattern will only be executed for non null object.

Compile and Run

As record released as preview feature with JDK 14, you need to enable preview to play around with it. To compile a class follow command like below

  javac --enable-preview --release 14 <Path of Java Source File>

it will compile and create class. Now to run it simply use java command with enable preview.

If you want to leverage the JDK 11 feature where a single source file can be directly compile and run with single java command follow below command.

  java --enable-preview --source 14 <Path of Java Source File>

TextBlocks

Ashish Garg — Sun, 23 Feb 2020 04:40:09 +0000

In Java writing multi line strings is not a fun, you must have written code where requirement is to put HTML, JSON, XML or SQL query as String in your code.

See below example where we are trying to place JSON as String

String sampleJson = "{\"name\":\"josh\",\"salary\":\"8000$\",\"age\":27,\"isMarried\":\"True\"}";

here we have a very simple JSON with lot many escape sequence, it’s very hard to read.

we can do better to make it readable, see below

String sampleJsonReadableABit = "{" +
        "\"name\":\"josh\"," +
        "\"salary\":\"8000$\"," +
        "\"age\":27," +
        "\"isMarried\":\"True\""+
        "}";

It’s better than earlier but still hard to read (lots of concatenation and escape sequences) and error prone. Adding or removing another attribute not easy for any developer.

Primary objective behind introducing Text Blocks is to

Ease to write multi line strings
Remove escape sequence and enhance readability
Handle white spaces and indentation intelligently

What is Text Blocks?

Text blocks were released as preview feature with JDK 13 in June 2019 based on feedback this is previewed again as JEP 368 with JDK 14.

This feature missed by developer from a long time specially when someone has to read such code where JSON document or SQL statements are embedded.

As definition “**A Text Block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired**”.

Text Block is defined with three double quotes “”” as opening and closing delimiter.

Let’s see how above JSON will be presented via Text Blocks

String jsonAsTextBlocks =  """
        {
        "name":"josh",
        "salary":"8000$",
        "age":27,
        "isMarried":"True"
        }
         """;

is it not better to read? No escape sequences :)

This feature is available with languages like Kotlin, Scala or Groovy.

Important Points

Opening delimeter, must be followed by a line terminator before content actually starts, trying to write TextBlocks like below will be a compile time error.

String textBlockSample = """Ashish //Compile time error
        """;
String textBlockSampleTwo = """Ashish"""; //Compile time error
String textBlockSampleThree = """"""; //Compile time error
String textBlockSampleFour = """ """; //Compile time error

!! In first example content placed just after opening delimiter “”” without line terminator. This is not allowed and will be a compile time error.

!! In second example also content placed directly between opening “”” and closing delimiter “”” without line terminator (Usually with string we write something like **String str =”Ashish”**). This is also not allowed and will be a compile time error.

Having space between opening delimiter and line terminator will simply be ignored by compiler as content will only begin after line terminator.

Closing delimeter, no such rules. let's see some samples

String textBlockSample = """ //valid syntax
        Ashish""";
String textBlockSampleTwo = """ //valid syntax
        Ashish
        """;
String textBlockSampleThree = """ //valid syntax (empty)
        """;

Incidental White Space, Text Block differentiates smartly differentiate between incidental white space from essential white space. The Java compiler automatically strips away the incidental white spaces

  String htmlAsTextBlocks = """
          <html>
             <body>
                  <h1>
                  Sample Heading
                  </h1>
             </body>
          </html>
               """;

If you run above code snippet output will be something like below,

  <html>
  ...<body>
  ........<h1>
  ........Sample Heading
  ........</h1>
  ...</body>
  </html>

any space before tag would be considered as incidental space and simply removed by compiler, but space which marked with **…** are not incidental such space will be considered as expected/desired/essential white space and respected by compiler.

If you want to explicitly add some space before content same can be controlled with closing delimiter “”” observe below snippet here closing delimiter has been moved left explicitly

  String htmlAsTextBlocksWithSpace = """
            <html>
                <body>
                    <h1>
                    Sample Heading
                    </h1>
                </body>
            </html>
  """;

it will have ouput like below:

                    <html>
                <body>
                    <h1>
                    Sample Heading
                    </h1>
                </body>
            </html>

here leading spaces marked by closing delimiter respected by compiler. Note closing delimiter has a role to control leading white space but it can’t put any effect on trailing white space e.g. if above code change like below

  String htmlAsTextBlocksWithSpace = """
          <html>
              <body>
                  <h1>
                  Sample Heading
                  </h1>
              </body>
          </html>
                                            """;

it will have output like

  <html>
     <body>
         <h1>
         Sample Heading
         </h1>
     </body>
  </html>

To specifically add some trailing white space, you can write something like:

  String textBlockWithTrailingSpace = """
          Ashish    \040""";

above text block length if you calculate, it will be 11.

Similarities between Text Blocks and String

Largely we can use Text Blocks wherever String usage is applicable e.g. if any method definition can take String variable as argument, we can pass TextBlock there.

private static void textBlocksAsString(String str){
    System.out.println(str);
}

above method can be called as “**textBlocksAsString(“””
I am Fun
“””);**”

This is perfectly valid syntax.

Traditional String values and text blocks are both compiled to the same type: String. The bytecode class file doesn’t distinguish whether a String value is derived from the traditional String or a text block. This implies that text block values are stored in the string pool as any normal String. Both == and equals will return true if they are referring to exactly same value. See below code snippet

String str = "Ashish";
String textBlock = """
        Ashish""";

if you runs something

System.out.println(str==textBlock);
System.out.println(str.equals(textBlock));

Both statement will print true but if you slightly change the above code to:

String str = "Ashish";
String textBlock = """
        Ashish
        """;

both == and equals will return false.

You can concatenate String and Text Blocks like you concatenate two Strings, see below

System.out.println( """
    Works
    is fun
    """
        +
        "Let's have some");

This is valid.

For certain business requirement we have to write code where String need to split based on certain regular expression and convert into a List. Such use cases also got simplified with Text Blocks

String fruits = "Apple,Orange,Mango";
List<String> fruitsList = new ArrayList<>();
Collections.addAll(fruitsList,fruits.split(","));
//Such operation will be simplified like below
String fruitsTextBlocks = """
        Apple
        Orange
        Banana
        """;
List<String> lisOfFruits = fruitsTextBlocks.lines().collect(Collectors.toList());

Compilation Steps

Text Block processed by compiler in three steps:

Line Terminator — Windows and Linux has different line ending, windows use carriage return and line feed (“\r\n”) and Linux only use line feed (“\n”). To avoid any issues when source code transferred one OS to another, Text Blocks normalize line ending to \u000a. The escape sequences \n (LF), \f (FF), and \r (CR) are not interpreted during normalization; escape processing happens later.
Remove incidental white space — Above steps do normalization, in this steps all incidental white space will be remove as explained above. The escape sequences \b (backspace) and \t (tab) are not interpreted by the algorithm; escape processing happens later.
Interpret escape sequence — If your Text Block has any escape sequence it will be interpreted now. Text blocks support all of the escape sequences supported in string literals, including \n, \t, \’, \”, and \.

Escape Sequence

Handling of escape sequence "

It’s perfectly valid to have escape sequence “ in Text Block, see below

  String textBlockWithES = """
      When your "work" speaks for yourself don't Interrupt
      """;

but if you are trying to put it just adjacent to closing delimiter like below:

  String textBlockWithESI = """
      When your "work" speaks for yourself don't "Interrupt"""";

It will be a compile time error, it can be solved in two ways:

Take closing delimeter to next line.

 String textBlockWithESI = """
     When your "work" speaks for yourself don't "Interrupt"
     """;

Use escape

  String textBlockWithESI = """
      When your "work" speaks for yourself don't "Interrupt\"""";

This escape character \ can be placed before any “ among last four (“”””) in above line.

Text Block can be embedded into another text block- if you are trying to put triple “”” in text block in any place other then opening and closing delimiter you have put escape character else it will be a compile time error:

  String textBlockWithESII = """
      When your "work" \""" speaks for yourself don't "Interrupt\"""";
  //Above is a valid Text Block

On similar line if you need to embed another Text Block inside a text block you have to use escape character

  String textBlockWithAnotherEmbedded =
          """
          String text = \"""
              A text block inside a text block
          ""\";
          """;

### New Escape Sequences

It’s a very common practice/requirement where a long string divided into multiple substring concatenated them with ‘+’ to maintain the code readability but output will be a single line. To handle similar requirement new escape sequence \ added in java this will only work with TextBlocks.

  String quoteAsStr = "Fearlessness is like a muscle. " +
          "I know from my own life that the more I exercise it, " +
          "the more natural it becomes to not let my fears run me.";

  System.out.println(quoteAsStr);
  String quoteAsTextBlocks = """
          Fearlessness is like a muscle. \
          I know from my own life that the more I exercise it, \
          the more natural it becomes to not let my fears run me.""";
  System.out.println(quoteAsTextBlocks);

if you execute above code, both print output will be exactly same

  Fearlessness is like a muscle. I know from my own life that the more I exercise it, the more natural it becomes to not let my fears run me.

  Fearlessness is like a muscle. I know from my own life that the more I exercise it, the more natural it becomes to not let my fears run me.

Another new escape sequence \s added with this JEP, is to simply translates to a single space (\u0020). Escape sequences aren’t translated until after incident space stripping, so \s can act as fence to prevent the stripping of trailing white space. This escape sequence applicable on both String and Text Blocks.

  String colors = """
          red  \s""";
  System.out.println(colors.length());

on console output will be 6.

New Methods

String::stripIndent()

As we discussed above compiler removes incidental white spaces from Text Blocks, this method added in String to achieve same result with normal String.

  String fruitsStr = "red\n   green\n   blue";
  System.out.println(fruitsStr);
  //1- It will print 
  //red
  //   green
  //   blue
  System.out.println(fruitsStr.replace(" ","."));
  //2- It will print
  //red
  //...green
  //...blue
  System.out.println(fruitsStr.stripIndent());
  //3- It will print
  //red
  //   green
  //   blue

In above snippet, you can observe there is no impact of stripIndent() method as there is no incidental white space found by compiler but if you have a string like below:

  String fruitsStrWithLeadingSpace = "  red\n   green\n   blue";
  System.out.println(fruitsStrWithLeadingSpace);
  //1- It will print
  //  red
  //   green
  //   blue
  System.out.println(fruitsStrWithLeadingSpace.replace(" ","."));
  //2- It will print
  //..red
  //...green
  //...blue
  System.out.println(fruitsStrWithLeadingSpace.stripIndent());
  //3- It will print
  //red
  // green
  // blue

Here you can see between second and third console print leading white space has been removed from String.

String::translateEscapes()

As name implies this will translate escape sequence present in String, see below example

  String fruitsStr = "red\n   green\\n   \"blue\"";
  System.out.println(fruitsStr);
  //1- It will print
  //red
  //   green\n   "blue"
  System.out.println(fruitsStr.translateEscapes());
  //2- And after translateEscape, it will print
  //red
  //   green
  //   "blue"

you can observe that new line character has been translated in 2- console print.

String::formatted(Object… args)

String jsonAsTextBlocks =  """
{
"name":"%s"
}
 """.formatted("Ashish");
System.out.println(jsonAsTextBlocks);
//It will print
//{
//"name":"Ashish"
//}

It work very similar to String.

Hope you guys have enjoyed this.

Disclaimer

It has been published before on medium https://medium.com/analytics-vidhya/text-blocks-jep-368-56c1625f97cf

What's coming in JDK 14

Ashish Garg — Sat, 22 Feb 2020 13:09:19 +0000

JDK 14 is due to release March 2020, feature supposed to part of this release has been frozen. A list of JEPs identified for inclusion:

JEPs

These JEPs can be divided into two parts from feature perspective:

Finalized

(JEP 345) NUMA aware memory allocation for G1
(JEP 349) JFR Event Streaming
(JEP 352) Non-Volatile mapped with Byte Buffers
(JEP 358) Helpful NullPointerExceptions
(JEP 361) Switch Expressions

Preview or Incubating

(JEP 305) Pattern Matching for instanceof
(JEP 343) Packaging Tool
(JEP 359) Records
(JEP 368) Text Blocks
(JEP 370) Foreign-Memory Access API

Stuffs that has been removed or deprecated are covered under

(JEP 362) Deprecate the Solaris and SPARC Ports
(JEP 363) Remove the Concurrent Mark Sweep (CMS) Garbage Collector
(JEP 366) Deprecate the ParallelScavenge + SerialOld GC Combination
(JEP 367) Remove the Pack200 Tools and API

ZGC (Garbage Collector) before JDK 14 was supported on Linux only, it has been extended for

(JEP 364) ZGC on macOS
(JEP 365) ZGC on Windows

I will be covering JEPs which are finalized first then I be touching preview/Incubator as well.

Switch Expressions (JEP 361)

This was released as preview feature in JDK 12 and JDK 13 and It has been standardized (freezes) with JDK 14 incorporating feedback from developer community. Existing implementation of Switch follows the design and syntax of C and C++ and supports fall through.

Before talking about switch expressions let's first understand shortcoming of existing switch statement:

Fall through behaviour between switch labels
Default scoping in switch blocks (the whole block is treated as one scope)
Quite verbose, not easy to read as more ‘breaks’ add into switch block

This JEP introdcued below changes

A new form of switch label, “case L ->”, to signify that only the code to the right of the label is to be executed if the label is matched
If a label is matched, then only the expression or statement to the right of the arrow is executed; there is no fall through
Switch statement are extended so they can be used as expression
Most switch expression will have a single value to right of ‘case ->’, in case you need block ‘yield’ has been introduced
In case of switch expression a default case is required to emphasize that all possible cases are considered, default case can be skipped if you are using Enum as case identifier, compiler can see if all cases are covered or not

Helpful NullPointerExceptions (JEP 358)

This JEP introduced NPE message to specifically tell which variable is actually caused this exception. Existing log message will tell you filename and line from where NPE has been thrown but it will not tell you that which variable caused this

With this JEP i.e. NPE from assignment obj.temp = 10; could generate:

Exception in thread “main” java.lang.NullPointerException:
Cannot assign field “temp” because “obj” is null
at Test.main(Test.java:6)

Note:- Only NPEs that are created and thrown directly by the JVM will include the null-detail message. NPEs that are explicitly created and/or explicitly thrown by programs running on the JVM are not subject to the bytecode analysis and null-detail message.

In addition, the null-detail message is not reported for NPEs caused by code in hidden methods, which are special-purpose low-level methods generated and called by the JVM to, e.g., optimize string concatenation. A hidden method has no filename or line number that could help to pinpoint the source of an NPE, so printing a null-detail message would be futile.

This feature is not enabled by default, it can be enabled by command-line option -XX:+ShowCodeDetailsInExceptionMessages. It’s not turned on by default because:

Performance - Algorithm add some overhead to the production of stack trace
Security - Detail message give information about insight of source code, you might not want this for production applications
Compatibility - Some tool might got broken because of this new message format

Feature flag might not be required for future JDK releases

Computation of detail NPE message might not work in below scenario

When executing remote code via RMI
If the bytecode instructions of a method change while a program is running, such as due to redefinition of the method by a Java agent using JVMTI

Non-Volatile mapped with Byte Buffers (JEP 352)

Primary goal is allows java program to update NVM (Non-volatile Memory) from a java program efficiently and coherently. The target OS/CPU platform combinations for this JEP are Linux/x64 and Linux/AArch64. This restriction is imposed for two reasons. This feature will only work on OSes that support the mmap system call MAP_SYNC flag, which allows synchronous mapping of non-volatile memory. That is true of recent Linux releases. It will also only work on CPUs that support cache line writeback under user space control. x64 and AArch64 both provide instructions meeting this requirement.

Note - Recent Windows/X64 releases do support the mmap MAP_SYNC flag, however it’s not supported by this JEP as of now.

NVM offers the opportunity for application programmers to create and update program state across program runs without incurring the significant copying and/or translation costs that output to and input from a persistent medium normally implies. This is particularly significant for transactional programs, where regular persistence of in-doubt state is required to enable crash recovery.

NUMA aware memory allocation for G1 (JEP 345)

Modern multi-socket machines increasingly have non-uniform memory access (NUMA), that is, memory is not equidistant from every socket or core. Memory accesses between sockets have different performance characteristics, with access to more-distant sockets typically having more latency.

Large enterprise applications in particular tend run with large heap configurations on multiple sockets, yet they want the manageability advantage of running within a single JVM.

G1’s heap is organized as a collection of fixed-size regions. A region is typically a set of physical pages, although when using large pages (via -XX:+UseLargePages) several regions may make up a single physical page.

If the +XX:+UseNUMA option is specified then, when the JVM is initialized, the regions will be evenly spread across the total number of available NUMA nodes.

JFR Event Streaming (JEP 349)

To consume the data today, a user must start a recording, stop it, dump the contents to disk and then parse the recording file. This works well for application profiling, where typically at least a minute of data is being recorded at a time, but not for monitoring purposes. An example of monitoring usage is a dashboard which displays dynamic updates to the data.

Under this JEP, an API has been introduced which can asynchronously publish event to all subscribers which much lower overhead.

Pattern Matching with InstanceOf(JEP 305)

All Java programmers are familiar with the instanceof-and-cast idiom:

private static void instanceOfExist(Object obj){  
  if(obj instanceof String){
        String s =(String)obj;
        //use s
    }
}

This is bit weird event after testing a instance type you have do explicit casting and assignment which is not optimal, This JEP has been implemented to address it via pattern matching.

After this JEP above code coule be written like this:

private static void newInstanceOf(String str){
    if(str instanceof String s){
        // can use s here
    }else{
        // can't use s here
    }
}

The instanceof operator “matches” the target obj to the type test pattern as follows: if obj is an instance of String, then it is cast to String and assigned to the binding variable s. The binding variable is in scope of true block and not in the false block of if statement.

Packaging Tool (JEP 343)

To run a java application typically we need JVM to install and running on a machine. This JEP has been target to come up with a packing tool which can generate binary in native format. These formats include msi and exe on Windows, pkg and dmg on macOS, and deb and rpm on Linux.

There is no GUI for this tool, supported as CLI only.

Packaging tool will be platform specific i.e. to generate a binary (exe) for windows you need to run packaging tool on windows only.

Developers can use jlink to strip the JDK down to the minimal set of modules that are needed, and then use the packaging tool to produce a compressed, installable image that can be deployed to target machines.

An application image contains both the files comprising your application as well as the JDK runtime image that will run your application.

Non-modular Applications

Suppose you have an application composed of JAR files, all in a directory named lib, and that lib/main.jar contains the main class. Then the command

$ jpackage — name myapp — input lib — main-jar main.jar

will package the application in the local system’s default format, leaving the resulting package file in the current directory.

Modular Applications

If you have a modular application, composed of modular JAR files and/or JMOD files in a lib directory, with the main class in the module myapp, then the command

$ jpackage — name myapp — module-path lib -m myapp

Records (JEP 359)

In an enterprise application we create lots of the classes as data carrier. To write a proper data carrier a developer need to write a lot of code i.e. constructors(), toString(), hashcode(), equals() etc. which is repeatable and error prone even I often notices developers are skipping to wrote these methods which resultant to production issues.

Most of IDEs these days help to generate such code but reader still not able to recognized which class wrote by developer as pure intention of data carrier.

This JEP has been targeted with the intention that It should be easy, clear, and concise to declare shallowly-immutable, well-behaved nominal data aggregates.

Records are a new kind of type declaration in the Java language. Like an enum, a record is a restricted form of class. A record has simply a name and state description. For Example:

record Point(int x, int y) { }

A record get many standard functionality automatically:

A private final field for each component of the state description
A public read accessor method for each component of the state description, with the same name and type as the component
A public constructor, whose signature is the same as the state description, which initializes each field from the corresponding argument
Implementations of equals and hashCode that say two records are equal if they are of the same type and contain the same state; and
An implementation of toString that includes the string representation of all the record components, with their names

Note- Any of the members that are automatically derived from the state description can also be declared explicitly. However, carelessly implementing accessors or equals/hashCode risks undermining the semantic invariants of records.

Similar functionality exist in other OO languages based on JVM i.e. data classes in Kotlin and case classes in Scala.

### Restriction of Records

Cannot extend another class
Cannot declare instance field other than private final other declared field must be static
Records are implicitly final, and cannot be abstract

TextBlocks (JEP 368)

It’s initially introduced with JDK 13 as preview feature, it has been re-preview again with JDK 14 with certain modification.

A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired.

Have you ever embedded a snippet of HTML, XML, SQL, or JSON in a string, do you like all escape and new line sequences need to be added?

Here how we write today:

String html = “<html>\n” +
“ <body>\n” +
“ <p>Hello, world</p>\n” +
“ </body>\n” +
“</html>\n”;

After this JEP, we can write same as

String html = “””
<html>
<body>
<p>Hello, world</p>
</body>
</html>
“””;

Text blocks do not directly support string interpolation. Interpolation may be considered in a future JEP.

Foreign Memory Access API (JEP 370)

Introduce an API, to safely access and efficiently access memory outside Java heap. Many existing java library access foreign memory; those are in business of cache i.e. memcached.

Introduces three main abstractions:

MemorySegment is used to model a contiguous memory region with given spatial and temporal bounds
MemoryAddress can be thought of as an offset within a segment
MemoryLayout is programmatic description of a memory segment’s contents

Deprecate the Solaris and SPARC Ports (JEP 362)

Deprecate the Solaris/SPARC, Solaris/x64, and Linux/SPARC ports, with the intent to remove them in a future release

Remove the Concurrent Mark Sweep (CMS) Garbage Collector (JEP 363)

More than 2 years CMS was marked deprecated, it has been removed from JDK14 with this JEP. G1 is default garbage collector with JDK 14.

Deprecate the ParallelScavenge + SerialOld GC Combination (JEP 366)

There is one combination of GC algorithms that is rarely used in production application but requires a significant amount of maintenance effort: The pairing of the parallel young generation GC (called ParallelScavenge) and the serial old GC (called SerialOld).

As this combination has been deprecated, trying to use it will display a warning.

In future depends upon community it might be un-deprecated or removed from JDK.

Remove the Pack200 Tools and API (JEP 367)

This JEP is for removing pack200 and unpack200 tools along with pack200 API. These had been marked deprecated with JDK 11.