Introduction

I’m Monica Labbao, Senior Android Developer of Commude Philippines.
I’ve been making Android apps for the past two and a half years, some of which are published in Google Play, others winning awards in hackathons, including a Unity3D application I made once. Besides Android development, I also have a hand developing a Universal Windows App. Right now I am working to become proficient in the entire mobile development landscape, so I can provide more value to the company and delight to our users.

Introduction

           Kotlin, since its first stable release back in February 15, 2016, has spiked in popularity as one of the go-to languages used in Android development. The JetBrains programmers based in Saint Petersburg, Russia, named the language after one of the islands found in Russia. Currently it is maintained by JetBrains and a number of open-source contributors.

Why would you switch to Kotlin?

           Kotlin is concise, not-so type strict, and has expanded functionalities not readily available in Java, such as lambdas. But Kotlin has functionalities that would make you hard-pressed to translate in Java.

• Fully operational with Java. [5]

          Kotlin works 100% perfectly with Java. You can call Kotlin code from Java code. And you can call Java code from Kotlin. This allows you to have an Android project written in both Java and Kotlin.

This example shows you perfectly that Kotlin can in fact work with Java code:

Figure 2: Kotlin Class extending a Java class

Figure 3: Decompiled Java class AppCompatActivity,
which Kotlin class MainActivity extended

• More concise than Java

          As Java is more verbose, it makes its developers more prone to errors. Kotlin, for instance, no longer requires ending each line of code with a semicolon.

Figure 4: Some lines of code in a Kotlin class

Figure 5: The same implementation, but in Java

Also, as field visibility is normally private now, you no longer need to explicitly define fields and methods as private in Kotlin if they had to be. [3]

• Kotlin is null-safe by default

NullPointerExceptions, left unhandled, cost app crashes at the conster- nation of the end-users, and if improperly handled, do not let the app crash but leave the customers wondering what went wrong. Tony Hoare, inventor of ALGOL W, who set the tone for the concept of having a NullPointerException, calls it his billion-dollar mistake:

I call it my billion-dollar mistake…At that time, I was de- signing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the tempta- tion to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Java has this problem with allowing null references Thus, Kotlin ad- dresses this problem by introducing null safety, so you can watch out for NullPointerExceptions before compile time.

References

[1] Andrey Breslav. Kotlin/Native Tech Preview: Kotlin without a VM. 2017.

[2] JetBrains. Kotlin Programming Language, 2016.

[3] Logan Johnson. Kotlin’s default visibility should be internal. 2016.

[4] Marcin Moskala. Multiplatform native development in Kotlin. Now with iOS! 2017.

[5] Magnus Vinther. Why you should totally switch to Kotlin. 2017.