Why I love Java

So , I recently completed a course on Coursera named “Kotlin for Java Developers” and therefore I feel I am the right person for one of the most hot trending question “Kotlin or Java”.

Nowadays it’s difficult to find a Java developer who has not heard of Kotlin, also because Kotlin got a big back support of Google.

There are numerous advantages Kotlin has , to name a few -

1. KOTLIN SYNTAX IS WAY TOO PRECISE COMPARED TO JAVA

Less lines of code , same meaning , easy refactoring , easy debugging but all of this comes at the cost of more COMPILATION time. Here’s an example:

2. Kotlin Handles the long problem of dealing with NULL.

One of the most common pitfalls in many programming languages, including Java, is that accessing a member of a null reference will result in a null reference exception. In Java this would be the equivalent of a NullPointerException or NPE for short.

Kotlin’s type system is aimed to eliminate NullPointerException's from our code. The only possible causes of NPE's may be:

An explicit call to throw NullPointerException()

Usage of the !!

Some data inconsistency with regard to initialization

In Kotlin, the type system distinguishes between references that can hold null (nullable references) and those that can not (non-null references). For example, a regular variable of type String can not hold null:

var a: String = "abc" // Regular initialization means non-null by default
a = null // compilation error

To allow nulls, we can declare a variable as nullable string, written String?:

var b: String? = "abc" // can be set null
b = null // ok
print(b)

There are also other methods of dealing with null in Kotlin such as -

Checking for null in conditions

First, you can explicitly check if b is null, and handle the two options separately:

val l = if (b != null) b.length else -1

The compiler tracks the information about the check you performed, and allows the call to length inside the if. More complex conditions are supported as well:

val b: String? = "Kotlin"
if (b != null && b.length > 0) {
print("String of length ${b.length}")
} else {
print("Empty string")
}

Safe Calls

Your second option is the safe call operator, written ?.:

val a = "Kotlin"
val b: String? = null
println(b?.length)
println(a?.length) // Unnecessary safe call

This returns b.length if b is not null, and null otherwise. The type of this expression is Int?.

Elvis Operator

When we have a nullable reference b, we can say "if b is not null, use it, otherwise use some non-null value":

val l: Int = if (b != null) b.length else -1

Along with the complete if-expression, this can be expressed with the Elvis operator, written ?::

val l = b?.length ?: -1

If the expression to the left of ?: is not null, the elvis operator returns it, otherwise it returns the expression to the right. Note that the right-hand side expression is evaluated only if the left-hand side is null.

Also another important feature I would like to mention is that -

Kotlin standard library is a collection of both Java Standard Library and it’s own personal extensions

What this means is that you can use Java’s standard built in libraries along with additional Kotlin’s own library.

Now what I feel after coding for atleast a month now in Kotlin is that the easiness of this language is what makes it a bit difficult to grasp .

The most important thing to take into account when designing a programming language should be how natural it is for humans to read and write it, and I believe Java creators did a really good job here.

On the other hand, with kotlin even nowadays I have trouble reading through code; it is far from intuitive.

Other reasons why I would prefer Java over Kotlin are-

Classes are not final by default

Every class should be able to be inherited from unless explicitly stated otherwise.

public class Dog {
}

public class Pomerania extends Dog {
}

This is OOP! Not only interfaces and abstract classes are designed to be extended, and many of our design templates rely on inheritance.

Kotlin doesn’t have that. We are forced to use the open keyword to explicitly tell we want to be able to extend every non abstract class we will create children for.

C notation for types

This is a classic: Type variable = value; . It reads almost like English and it’s been there since very long ago for a reason. For functions/methods it also works perfectly: Type function() {} .

And what did the Kotlin developers decide to do here? The complete opposite, going back to Pascal times and placing the type at the right a la var/val variable: Type = value.

No implicit executable code

In Java we have full control of our application’s code and we can rely on the fact that the compiler will never go crazy and generate code for us. This allows us to keep trusting breakpoints for any kind of debugging.

Kotlin is designed to generate the primary constructor, all the field getters/setters and even equals, hashCode and toString if you’re crazy enough to use data classes.

Practice and coding a lot in it will make you expert in this too but as far my preferences or interests are concerned I would still prefer JAVA whether it be because of the command I have in that language or I am more used to it’s syntax.