Java and Kotlin: A Practical comparison (part I)

Brief History of Kotlin

Kotlin was developed by JetBrains in 2010 and released in 2016. JetBrains open-sourced the project under the Apache 2 license in 2012, and Kotlin v1.0 was released on 2016.
The company behind IntelliJ IDEA, needed a language that was concise, elegant, expressive, and interoperable with Java, as most of their products were developed in Java. They aimed to reduce the amount of boilerplate code. As a result, although Kotlin is less powerful than Scala, it is much simpler and more importantly, communicates easily with Java code.
Spring Framework 5.0 introduced dedicated Kotlin support and it is the recommended language for Android development since 2017.

Language Philosophy

• Purely Object-oriented with functions as first class citizens.
• Safety through null-types and immutability.
• Extensibility through extension functions.
• Good tooling support.

It allows a gradual migration from Java. That does not happen with Scala.

Object Orientation

Java code

public class Person {

    private final String name;
    private int age;

    // Constructor with name and age
    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // Constructor with name only
    public Person(String name) {
        this(name, 0); // Default age is 0
    }

    public void plus(int lifetime) {
        this.age += lifetime;
    }

    // Getters
    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    // Factory method
    static Person newBorn(String name) {
        return new Person(name);
    }
}

Kotlin code

data class Person(val name: String,
             var age: Int = 0) {

    companion object {       // Factory method
        fun newBorn(name: String) = Person(name)
    }
}

• Default arguments allow to have only one constructor in Kotlin.
• Kotlin has no primitives. Everything is an Object.

• Every Kotlin method has a return type, which can be inferred. If the method is void, the return type is Unit. This is taken from Scala.

• An object in Kotlin is a singleton. The functions defined inside are equivalent to static Java methods.

• A data class generates the corresponding getters (and setters for mutable fields), as well as the hashCode, toString and equals methods. Also a copy method.
  This is taken from case class in Scala.
  

val alice = Person("Alice", 42)

alice == Person("Alice", 42)  // Equality by value, not by reference
res1: true

• This copy method is not generated by the Lombok annotations.
• Named arguments allows to use any parameters order

val john = alice.copy(name = "John")

• Destructuring, like in Javascript and in Python

val (name, age) = alice   

A record class, introduced in the latest Java versions, generates most of the methods shown above. The final code is almost equivalent to that obtained with Lombok annotations.

Java 14 and higher

public record Person(String name, int age) {

    public Person(String name) {
        this(name, 0); // Default age is 0
    }

    static Person newBorn(String name, int age) {
        return new Person(name, age);
    }
}

final var alice = new Person("Alice", 42)
alice == new Person("Alice", 42)  

// copy() does not exist

// destructuring does not exist either

// The new keyword is required.
// The semicolons are required.

NOTE: this article is the first one of a long series comparing Java and Kotlin. Please stay tuned for the next part.
I will try to post once a week.

Comments

[Sergiy Yevtushenko]

• Destructuring in Java exists in pattern matching.
• Lack of copy method generated by compiler can be compensated with annotation processor. There are plenty of them, Lombok is not alone (and, to my taste, the worst of them). Take a look, for example, at github.com/Randgalt/record-builder .
• Return type inference is usually banned in project rules because it significantly complicates reading the code.
• If the new keyword and semicolons are an issue, then 'fun', 'companion object', and colons in type declarations are an issue too.

Kotlin was chosen by Google, not because of Kotlin properties. Google just required a replacement for Java in case if it will lose legal battle with Oracle.