Mala Gupta [Mala Gupta] - Java 11 Quick Start

The contract of the public API should be explicit, they shouldn't depend on type inference.

Imagine you want to limit the values that can be passed to a field in your data class during its instantiation. This is feasible, just override the default constructor. Here's an example:

record Emp(String name, int age) { // override default constructor @Override public Emp(String name, int age) { // validate age if (age > 70) throw new IllegalArgumentException("Not employable above 70 years"); else { // call default constructor default.this(name, age); } } }

Similarly, you can also override the default implementation of object methods such as equals(), hashCode() and toString() and others methods such as the accessor methods.

Overriding the default behavior of the methods of your data class, doesn't defeat the purpose of their creation. They are still working as data classes, with finer control on their working. Let's compare it with the POJOs, which were earlier used to model data classes. The compiler doesn't auto-generate any methods for a POJO. So, a user still needs to read all the code, looking for code that isn't the default implementation of its methods. In case of the data classes, this overridden behavior is very explicit. So, a user doesn't have to worry about reading all the code, he/she can assume default implementation of the behavior, which hasn't been overridden by the developer.

The following lines of code show how you have been defining your local variable (and all other variables), prior to Java 10:

String name = "Java11"; LocalDateTime dateTime = new LocalDateTime.now();

Starting with Java 10, using var, you can drop the mandatory explicit type in the declaration of local variables, as follows:

var name = "Java11"; // variable 'name' inferred as String var dateTime = new LocalDateTime.now(); // var 'dateTime' inferred as LocalDateTime

Do you think that the preceding code doesn't seem to offer a lot of benefits? What if, instead of the following?

HashMap map = new HashMap();

You could use the following:

var map = new HashMap();

The preceding example drops quite a lot of letters on the left-hand side, making it leaner.

When you move away from stating the data type of the variables explicitly, the compiler takes over to determine or infer the variable type. Type inference is compiler's ability to evaluate the information already present in the code, like, the literal values, operations, method invocation or their declaration to determine the variable type. It follows a set of rules to infer the variable type. As a developer, when you choose type inference with var, you should be aware of compiler's inference algorithm and other rules, so that you don't get unexpected results.

With every new feature, you should adhere to a few rules, restrictions and try to follow best practices to benefit from it. Let's start with the compulsory initialization of the variables that are defined using var.

Let's get started by re-defining the Emp class, which we used in the beginning of the chapter, as a data class:

record Emp(String name, int age) { } // data class - one liner code

The preceding code uses the keyword record to define a data class, accepting comma separated variable name and type, required to store the state. The compiler automatically generates default implements for the Object methods (equals(), hashCode(), toString()) for data classes.

The code looks clear and compact. A reader would immediately know the intent of this single line of code, a carrier of data name (type String) and age (type int). Another advantage for a reader is that she wouldn't need to read through constructors, accessors, mutators, or methods of the object class, just to ascertain that they are doing what they are supposed to, not more, which they should be aware of.

Behind the scenes, the record class Emp is converted to the following by the Java compiler:

final class Emp extends java.lang.DataClass { final String name; final int age; public Emp(String name, int age) { this.name = name; this.age = age; } // deconstructor // public accessor methods // default implementation of equals, hashCode, and toString }

The preceding data class is an example of a non-abstract data class. A data class can also be defined as an abstract data class. A non-abstract data class is implicitly final. In both cases, a data class would get default implementations of hashCode(), equals() and toString(), and accessor methods. For an abstract data class, the constructors would be protected.

In the following image, the compiler looks happy to convert one liner code for the data class, to a full-fledged class: