• En
  • /
  • Jp
  • Transitioning from Java to Kotlin

    2018.11.13
    • Share
    • Twitter
    • Google+
    • はてなブックマーク
    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.

    What is Kotlin?

               Kotlin, as it is officially defined by its creators, is a statically typed programming language for modern applications. [2] It is fully interoperable with Java and with Android. Other uses for Kotlin include iOs development. [4] Kotlin compiles to Javascript, on the Java Virtual Machine, and to machine code. [1] According to JetBrains development lead Andrey Breslav, Kotlin is designed to be an industrial-strength object-oriented language, to be a ”better language” than Java, but still fully interoperable with Java code, allowing companies to make a gradual migration from Java to Kotlin.

               As of Android Studio 3.0 (October 2017), Kotlin is now fully supported by Google for use with the Android operating system as an alternative to the Java compiler.

    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.
    to be continued…