Kotlin could overtake Java on Android next year!

Now that Google has endorsed Kotlin for Android development, Java-based mobile developers could become dinosaurs!

Kotlin is on its way to overtaking Java on that mobile platform, claims mobile database maker Realm.

Realm performed an anonymized assessment of 100,000 developers using its database and which languages they were using, determined by developers’ selection of SDKs. Realm found that 20 percent of apps built with Java before Google’s May endorsement of Kotlin are now being built in Kotlin.

Based on that data, Realm predicts Kotlin will overtake Java on Android by December 2018. Kotlin may even change how Java is used on the server, the company said: “In short, Android developers without Kotlin skills are at risk of being seen as dinosaurs very soon.”

In September 2016, Kotlin accounted for 5.1 percent of Android development versus 94.9 percent for Java, Realm’s data shows. A year later, it’s 14.3 percent for Kotlin versus 85.7 percent for Java. When Google endorsed Kotlin in May, the numbers were  7.4 percent for Kotlin and 92.6 percent for Java.

Real says Kotlin’s growth is due to its modernity. “Kotlin is a much more modern language,” Realm chief marketer Paul Kopacki said. “It’s easier to understand, it’s easier to write, it’s a little higher in abstraction than Java, and it’s really been designed with mobile in mind.”

Kotlin for Android

Up until May 2017, the only officially supported programming languages for Android were Java and C++. Google announced official support for Kotlin on Android at Google I/O 2017, and starting with Android Studio 3.0 Kotlin is built into the Android development toolset. Kotlin can be added to earlier versions of Android Studio with a plug-in.

Kotlin compiles to the same byte code as Java, interoperates with Java classes in natural ways, and shares its tooling with Java. Because there is no overhead for calling back and forth between Kotlin and Java, adding Kotlin incrementally to an Android app currently in Java makes perfect sense. The few cases where the interoperability between Kotlin and Java code lacks grace, such as Java set-only properties, are rarely encountered and easily fixed.

Pinterest was the poster child for Android apps written in Kotlin as early as November 2016, and it was mentioned prominently at Google I/O 2017 as part of the Kotlin announcement. In addition, the Kotlin team likes to cite the Evernote, Trello, Square, and Coursera apps for Android.

Kotlin vs. Java

The question of whether to choose Kotlin or Java for new development has been coming up a lot in the Android community since the Google I/O announcement, although people were already asking the question in February 2016 when Kotlin 1.0 shipped. The short answer is that Kotlin code is safer and more concise than Java code, and that Kotlin and Java files can coexist in Android apps, so that Kotlin is not only useful for new apps, but also for expanding existing Java apps.

The only cogent argument I have seen for choosing Java over Kotlin would be for the case of complete Android development newbies. For them, there might be a barrier to surmount given that most Android documentation and examples are in Java. On the other hand, converting Java to Kotlin in Android Studio is a simple matter of pasting the Java code into a Kotlin file.

For almost anyone else doing Android development, the advantages of Kotlin are compelling. The typical time quoted for a Java developer to learn Kotlin is a few hours—a small price to pay to eliminate null reference errors, enable extension functions, support functional programming, and add coroutines.

Kotlin vs. Scala

The question of whether to choose Kotlin or Scala doesn’t come up often in the Android community because the Android tool support for Scala just isn’t very good, and the Scala library for Android tends to be on the large side. On the other hand, the Scala community is keenly aware of the issues and is working on solutions for them.

In other environments, the situation is different. For example, Apache Spark is mostly written in Scala, and big data applications for Spark are often written in Scala.

In many ways both Scala and Kotlin represent the fusion of object-oriented programming, as exemplified by Java, with functional programming. The two languages share many concepts and notations, such as immutable declarations using val and mutable declarations using var, but differ slightly on others, such as where to put the arrow when declaring a lambda function, and whether to use a single arrow or a double arrow. The Kotlin data class maps to the Scala case class.

Kotlin defines nullable variables in a way that is similar to Groovy, C#, and F#; most people get it quickly. Scala, on the other hand, defines nullable variables using the Option monad, which can be so forbidding that some authors seem to think that Scala doesn’t have null safety.

One clear deficit of Scala is that its compile times tend to be long, something that is most obvious when you’re building a large body of Scala, such as the Spark repository, from source. Kotlin, on the other hand, was designed to compile quickly in the most frequent software development scenarios, and in fact often compiles faster than Java code.

Kotlin interoperability with Java

At this point you may be wondering how Kotlin handles the results of Java interoperability calls, given the differences in null handling and checked exceptions. Kotlin silently and reliably infers what is called a “platform type” that behaves exactly like a Java type, meaning that is nullable but can generate null-pointer exceptions. Kotlin may also inject an assertion into the code at compile time to avoid triggering an actual null pointer exception. There’s no explicit language notation for a platform type, but in the event Kotlin has to report a platform type, such as in an error message, it appends ! to the type.

In most cases, calling Java code from Kotlin works the way you might expect. For example, any time both getters and setters exist in a Java class, Kotlin treats them as properties with the same name. Similarly, Boolean accessor methods are treated as properties that have the same name as the getter method.


One Comment

Add a Comment

Your email address will not be published. Required fields are marked *