Why Kotlin Is Great For Android App Development

Part of the problem is that no one can agree on what constitutes perfect. People like to fight about things, including programming language features. With this in mind, you might feel sorry for Java as the victim of mean-spirited finger pointing by those who just don’t like the language.

However, as you’ll soon discover, Java has some real issues that Kotlin attempts to fix. Whether you agree with the fixes is a matter for you to decide, of course.

Kotlin improves control over null references

When you try to access an object that points to null in Java, you get the dreaded NullPointerException. Of course, the first thing on your mind is determining what happened to the house that’s supposed to appear on that empty lot.

Unfortunately, we’ve been dealing with the null reference since 1965, when Tony Hoare decided to add it to ALGOL W. He calls it his billion-dollar mistake during the 2009 QCon London presentation. When the inventor of a method of doing something says it was a horrid mistake, getting rid of it seems like a good idea. But getting rid of the null reference would mean breaking a lot of Java code, so that’s where Kotlin comes into play.

Kotlin doesn’t actually remove null references entirely, but it does help you control them better. For example, the following code results in a compilation error in Kotlin:

var a: String = "abc"
a = null
println(a)

Of course, there must be allowances. You can tell Kotlin to allow null values in specific cases by using a special operator. The following code defines a nullable String and will compile:

var a: String? = "abc"
a = null
println(a)

val a: String = "abc"
println(a.length)

val a: String? = "abc"
println(a.length)

val a: String? = "abc"
println(a?.length)

val a: String? = "abc"
val b = a?.length ?: 0
println(b)

val a: String? = null
println(a!!.length)

• The throw NullPointerException() being specifically called by the code.
• The use of the non-null assertion operator (!!), described earlier.
• A data inconsistency that results from improper initialization:
  • The this object found in a constructor is passed to some other code (called a “leaking this” problem).
  • A superclass constructor calls on an open member that is supposed to be initialized in a derived class, but isn’t.

• Your code calling Java code that produces a NullPointerException. Unfortunately, Kotlin can’t protect you from Java.

Kotlin removes raw data types

List names = Arrays.asList("John", "Mia", "Herb", "Ann");

Iterator iter = stars.iterator();
while(iter.hasNext()) {
  String name = (String) iter.next(); //cast needed
  println(name);
}

val names: List = 
   Arrays.asList("John", "Mia", "Herb", "Ann")
for (name in names){
    println(name)
}

Kotlin uses invariant arrays

String[] stuff = {"Tom", "Sam", "Ann"};
Object[] moreStuff = stuff;

String a = stuff[0];
System.out.println(a);
String b = moreStuff[0];
System.out.println(b);

String a = stuff[0];
System.out.println(a);
moreStuff[0] = 5;
String b = (String)moreStuff[0];
System.out.println(b);</pre<

List<String> stuff = Arrays.asList("Tom", "Sam", "Ann");
List<Object> moreStuff = stuff;

val stuff: Array<String> = arrayOf("Tom", "Sam", "Ann")
val moreStuff: Array<Any> = stuff

Kotlin lets you work with proper function types

However, Java developers can perform functional programming after a fashion by using techniques such as Single Abstract Method (SAM) conversions. To give you some idea of how functional programming differs from Java programming, here are the basic tenets:

• Creating functions that are first-class objects
• Using pure functions
• Employing higher-order functions
• Relying on a lack of function state
• Depending on an absence of side effects
• Using immutable variables
• Favoring recursion over looping

public class performSum{
    public int sum(int a, int b) {
        return a + b;
    }
}

Java’s lambda functionality relies on SAM, which is an interface version (also called a functional interface) of the pure function. Here’s an example of SAM:

public interface OnClickListener {
    void onClick(View v);
}

myView.setOnClickListener((view) -> logger.debug(
    "View Clicked!"));

fun setOnClickListener(listener: (view: View) -> Unit) {
   // ...
}

The main issue to consider when working with the Kotlin form of lambda expressions is that the Kotlin form is essentially incompatible with the Java form, making interop a lot more difficult to deal with. You can use the Java form of lambda expressions in Kotlin when working with Java code. However, when working with Kotlin code, you must use the Kotlin form instead, which means that you now have to know two ways of making lambda expressions work.

Kotlin gets rid of the checked exceptions

• Anders Hejlsberg
• Rod Waldhoff

Want to learn more? Check out this article discussing Kotlin.