A New Future for Java
By: The Bored Dev
Tags: Software Development, Android, Mobile, Java, Programming

The “Kotlinisation” of Java

Some of the upcoming Java features are going to be a massive improvement for Java in terms of readability and in terms of improving one of the main weaknesses in Java, its verbosity. We could affirm that they all have a suspicious similarity to some Kotlin features.

Please keep in mind that most of these features are feature previews. What that means is that if you install JDK 14 or JDK 15 when it gets released, you won’t be able to use them by default.

Java feature previews are new features that are introduced in a release but are disabled by default. They’re included in the release just to gather feedback from the community of developers, so they’re still subject to changes. That’s why it’s not recommended to use them in production code.

To enable them at compilation time, you’d have to do the following:

javac --enable-preview --release 14

If you want to enable them at runtime, you’d have to run the following:

java --enable-preview YourClass

Of course, you can also enable them in your IDE, but be careful to not enable previews by default in all your new projects!

Let’s take a look at those changes that are going to have a bigger impact on our coding with future versions of Java.

Java records

Java records are a feature that many of us have been demanding for a long time. I guess you’ve been in the same situation multiple times, when you reluctantly have to implement toString , hashCode , equals , and also getters for each existing field. (I’m assuming that you’re no longer using setters, and you definitely should not.)

Kotlin provides data classes to solve this problem, and Java is intending to do the same by releasing the record classes, something that Scala also has with its case classes.

The main purpose of these classes is to hold immutable data in an object. Let’s take a look at how much better will it be in Java by looking at an example. This is how much code we’d have to write to be able to instantiate and compare our Employee class:

And also the Address object it contains:

That’s a lot of code for something so simple, isn’t it?

Let’s take a look now at how it will look with the new Java records:

And also our Address class again:

This is exactly the same we wrote earlier with so much code. You will have to agree with me on this: This is amazing, the amount of code we’re going to save and how much simpler it is!

Let’s see now what the differences are in the new switch statement.

Improved switch statement

The new switch statements in Java solve some of the inherent problems of using switch statements in Java. Switch statements at this moment should always be avoided because they’re very error-prone and lead to code duplication. Currently, it’s very easy to leave a case uncovered, for example.

With the new switch statement, that problem is solved because it won’t compile if our switch statement doesn’t cover the whole range of the domain that belongs to the type we pass in to the switch.

To explain this with an example, we’re going to create a DayOfTheWeek enum in Java:

Having that, our switch is going to tell us what position in the week corresponds to that day. Let’s see first how can we currently do this using Java 11.

Using the current switch statement, we’d have to make use of a variable, and also, if we miss one of the days of the week, our code will compile perfectly. This is one of the problems of switch statements: It’s very error-prone.

So how does Java 14 improve the situation? Let’s quickly see how:

You will be able to see very quickly that the new switch statements can be used as an expression, not only as a statement.

The result is more concise and expressive. That would be enough to convince many of us to use them, but one of the main improvements is that now switch statements won’t compile if we don’t cover all the cases in our switch. It will show us the following error, for example:

Error:(9, 24) java: the switch expression does not cover all possible input values

From now on, it’ll be impossible to miss a case in our switch statements. That’s awesome, isn’t it?

This is very similar to Kotlin when statements, which you can read about in the documentation.

Let’s also take a look at the new text blocks.

Text blocks

Have you ever moaned about how ugly and difficult it was to assign a big blob of JSON to a variable in Java? Java will introduce multi-line strings that you can define by wrapping them between triple quotes. When this feature gets officially released, it’ll be much easier to define long strings in multiple lines.

Let’s take a look at the differences between the two modes. At the moment, if we want to store a formatted JSON in a variable, it looks as ugly as this:

On the other hand, when new text blocks get released, it’ll be as easy and clean as this:

I think that’s much better, don’t you agree? This is also something supported in Kotlin, as you can find in its type definitions.

So we’ve seen that Java is “inheriting” many of the solutions to its own problems from one of its competitors: Kotlin. We don’t know if this time Oracle has reacted right in time to combat the rise of Kotlin or if maybe it comes too late. Personally, I think that Java is taking the right steps forward, even if these changes were triggered in some way by its competitors and might come a bit late.

As mentioned earlier, if this article has triggered your interest in learning the Kotlin language, I’d recommend that you read “Kotlin in Action,” a very good book for Java developers starting in Kotlin.