What I Miss in Java, the Perspective of a Kotlin Developer

Java has been my bread and butter for nearly 20 years. A number of years in the past, I began to be taught Kotlin; I by no means regretted it.

Although Kotlin compiles to JVM bytecode, I typically have to jot down Java once more. Each time I do, I can’t cease pondering why my code does not look as good as in Kotlin. I miss some options that will enhance my code’s readability, expressiveness, and maintainability.

This publish just isn’t meant to bash Java however to record some options I would like to seek out in Java.

Immutable References

Java has immutable references because the starting:

• For attributes in courses
• For parameters in strategies
• For native variables

class Foo {

    ultimate Object bar = new Object();      // 1

    void baz(ultimate Object qux) {          // 2
        ultimate var corge = new Object();   // 3
    }
}

1. Can’t reassign bar
2. Can’t reassign qux
3. Can’t reassign corge

Immutable references are an amazing assist in avoiding nasty bugs. Curiously, utilizing the ultimate key phrase just isn’t widespread, even in broadly used initiatives. For instance, Spring GenericBean makes use of immutable attributes, however neither immutable technique parameters nor native variables; slf4j’s DefaultLoggingEventBuilder makes use of not one of the three.

Whereas Java means that you can outline immutable references, it is not obligatory. By default, references are mutable. Most Java code does not reap the benefits of immutable references.

Kotlin does not go away you a selection: each property and native variable must be outlined as both a val or a var. Plus, one can’t reassign technique parameters.

The var Java key phrase is kind of completely different. First, it is solely accessible for native variables. Extra importantly, it does not provide its immutable counterpart, val. You continue to want so as to add the static key phrase, which almost no one makes use of.

Null Security

In Java, there isn’t any technique to know whether or not a variable is null. To be specific, Java 8 launched the Non-obligatory sort. From Java 8 onward, returning an Non-obligatory implies the underlying worth will be null; returning one other sort implies it can’t.

Nonetheless, the builders of Non-obligatory designed it for return values solely. Nothing is obtainable within the language syntax for strategies parameters and return values. To deal with this, a bunch of libraries present compile-time annotations:

Clearly, some libraries are centered on particular IDEs. Furthermore, libraries are hardly appropriate with each other. So many libraries can be found that any individual on StackOverflow requested which one to make use of. The ensuing exercise is telling.

Lastly, utilizing a nullability library is opt-in. On the opposite aspect, Kotlin requires each sort to be both nullable or non-nullable.

val nonNullable: String = computeNonNullableString()
val nullable: String? = computeNullableString()

Extension Features

In Java, one extends a category by subclassing it:

class Foo {}
class Bar extends Bar {}

Subclassing has two major points. The primary situation is that some courses do not permit it: they’re marked with the ultimate key phrase. A few widely-used JDK courses are ultimate, e.g., String. The second situation is that if a technique outdoors our management returns a sort, one is caught with that sort, whether or not it comprises the needed habits or not.

To work across the above points, Java builders have invented the idea of utility courses, often named XYZUtils for the kind XYZ. A utility class is a bunch of static strategies with a non-public constructor, so it can’t be instantiated. It is a glorified namespace as a result of Java does not permit strategies outdoors courses.

This fashion, if a technique does not exist in a sort, the utility class can present a technique that takes the kind as a parameter and execute the required habits.

class StringUtils {                                          // 1

    non-public StringUtils() {}                                 // 2
    
    static String capitalize(String string) {                // 3
        return string.substring(0, 1).toUpperCase()
            + string.substring(1);                           // 4
    }
}

String string = randomString();                              // 5
String capitalizedString = StringUtils.capitalize(string);   // 6

1. Utility class
2. Stop instantiation of recent objects of this kind
3. static technique
4. Easy capitalization that does not account for nook instances
5. The String sort does not provide a capitalization performance
6. Use a utility class to issue this habits

Word that earlier, builders created such courses contained in the venture. These days, the ecosystem provides Open Supply libraries comparable to Apache Commons Lang or Guava. Do not reinvent the wheel!

Kotlin gives extension capabilities to resolve the identical situation.

Kotlin gives the flexibility to increase a category or an interface with new performance with out having to inherit from the category or use design patterns comparable to Decorator. We are able to obtain it by way of particular declarations referred to as extensions.

For instance, you possibly can write new capabilities for a category or an interface from a third-party library that you would be able to’t modify. Such capabilities will be referred to as within the traditional method as in the event that they have been strategies of the unique class. This mechanism is known as an extension perform.

To declare an extension perform, prefix its identify with a receiver sort, which refers back to the sort being prolonged.

With extension capabilities, one can rewrite the above code as:

enjoyable String.capitalize2(): String {                           // 1-2
    return substring(0, 1).uppercase() + substring(1);
}

val string = randomString()
val capitalizedString = string.capitalize2()                 // 3

1. Free-floating perform, no want for a category wrapper
2. capitalize() already exists in Kotlin’s stdlib
3. Name the extension perform as if it belonged to the String sort

Word that extension capabilities are resolved “statically”. They do not actually connect new habits to the present sort; they faux to take action. The generated bytecode could be very related (if not the identical) to one of many Java static strategies. Nonetheless, the syntax is far clearer and permits for perform chaining, which is unimaginable with Java’s method.

Reified Generics

Model 5 of Java introduced generics. Nonetheless, the language designers have been eager on preserving backward compatibility: Java 5 bytecode was required to work together flawlessly with pre-Java 5 bytecode. That is why generic sorts aren’t written within the generated bytecode: it is generally known as sort erasure. The alternative is reified generics, the place generic sorts could be written within the bytecode.

Generic sorts being solely a compile-time concern creates a few points. For instance, the next technique signatures produce the identical bytecode, and thus, the code just isn’t legitimate:

class Bag {
    int compute(Listing<Foo> individuals) {}
    int compute(Listing<Bar> individuals) {}
}

One other situation is methods to get a typed worth out of a container of values.
This is a pattern from Spring:

public interface BeanFactory {
    <T> T getBean(Class<T> requiredType);
}

Builders added a Class parameter to have the ability to know the kind within the technique physique. If Java had reified generics, it would not be mandatory:

public interface BeanFactory {
    <T> T getBean();
}

Think about if Kotlin had reified generics. We may change the above design:

interface BeanFactory {
    enjoyable <T> getBean(): T
}

And to name the perform:

val manufacturing facility = getBeanFactory()
val anyBean = getBean<Any>()               // 1

1. Reified generics!

Kotlin nonetheless must adjust to the JVM specification and be appropriate with the bytecode generated by the Java compiler. It will possibly work by way of a trick referred to as inlining: the compiler replaces the inlined technique calls by the perform physique.

This is the Kotlin code to make it work:

inline enjoyable <reified T : Any> BeanFactory.getBean(): T = getBean(T::class.java)

I’ve described 4 Kotlin options that I miss in Java on this publish: immutable references, null security, extension capabilities, and reified generics. Whereas Kotlin provides different nice options, these 4 are sufficient to make the majority of enhancements over Java.

For instance, with extension capabilities and reified generics plus a little bit of syntactic sugar, one can simply design DSLs, such because the Kotlin Routes and Beans DSL:

beans {
  bean {
    router {
      GET("/whats up") { ServerResponse.okay().physique("Howdy world!") }
    }
  }
}

Make no mistake: I perceive that Java has far more inertia to enhance as a language, whereas Kotlin is inherently extra nimble. Nonetheless, competitors is sweet, and each can be taught from one another.

Within the meantime, I will solely write Java when I’ve to, as Kotlin has turn into my language of selection on the JVM.

To go additional: