Kotlin vs. Java: All-purpose Uses and Android Apps

It’s true that Java lost the Android battle to Kotlin, which is now Google’s preferred language and therefore better suited to new mobile apps. But both Kotlin and Java offer many strengths as general-purpose languages, and it’s important for developers to understand the language differences, for purposes such as migrating from Java to Kotlin. In this article, we will break down Kotlin’s and Java’s differences and similarities so you can make informed decisions and move seamlessly between the two.

Are Kotlin and Java Similar?

Indeed, the two languages have a lot in common from a high-level perspective. Both Kotlin and Java run on the Java Virtual Machine (JVM) instead of building directly to native code. And the two languages can call into each other easily: You can call Java code from Kotlin and Kotlin code from Java. Java can be used in server-side applications, databases, web front-end applications, embedded systems and enterprise applications, mobile, and more. Kotlin is similarly versatile: It targets the JVM , Android, JavaScript, and Kotlin/Native, and can also be used for server-side, web, and desktop development.

Java is a much more mature language than Kotlin, with its first release in 1996. Though Kotlin 1.0 was introduced much later, in 2016, Kotlin quickly became the official preferred language for Android development in 2019. Outside of Android, however, there is no recommendation to replace Java with Kotlin.

Kotlin vs. Java: Performance and Memory

Before detailing Kotlin’s and Java’s features, we’ll examine their performance and memory consumption as these factors are generally important considerations for developers and clients.

Kotlin, Java, and the other JVM languages, although not equal, are fairly similar in terms of performance, at least when compared to languages in other compiler families like GCC or Clang. The JVM was initially designed to target embedded systems with limited resources in the 1990s. The related environmental requirements led to two main constraints:

• Simple JVM bytecode: The current version of JVM, in which both Kotlin and Java are compiled, has only 205 instructions. In comparison, a modern x64 processor can easily support over 6,000 encoded instructions, depending on the counting method.
• Runtime (versus compile-time) operations: The multiplatform approach (“Write once and run anywhere”) encourages runtime (instead of compile-time) optimizations. In other words, the JVM translates the bulk of its bytecode into instructions at runtime. However, to improve performance, you may use open-source implementations of the JVM, such as HotSpot, which pre-compiles the bytecode to run faster through the interpreter.

With similar compilation processes and runtime environments, Kotlin and Java have only minor performance differences resulting from their distinct features. For example:

• Kotlin’s inline functions avoid a function call, improving performance, whereas Java invokes additional overhead memory.
• Kotlin’s higher-order functions avoid Java lambda’s special call to InvokeDynamic, improving performance.
• Kotlin’s generated bytecode contains assertions for nullity checks when using external dependencies, slowing performance compared to Java.

Now let’s turn to memory. It is true in theory that the use of objects for base types (i.e., Kotlin’s implementation) requires more allocation than primitive data types (i.e., Java’s implementation). However, in practice, Java’s bytecode uses autoboxing and unboxing calls to work with objects, which can add computational overhead when used in excess. For example, Java’s String.format method only takes objects as input, so formatting a Java int will box it in an Integer object before the call to String.format.

On the whole, there are no significant Java and Kotlin differences related to performance and memory. You may examine online benchmarks which show minor differences in micro-benchmarks, but these cannot be generalized to the scale of a full production application.

Unique Feature Comparison

Kotlin and Java have core similarities, but each language offers different, unique features. Since Kotlin became Google’s preferred language for Android development, I’ve found extension functions and explicit nullability to be the most useful features. On the other hand, when using Kotlin, the Java features that I miss the most are the protected keyword and the ternary operator.

Let’s examine a more detailed breakdown of features available in Kotlin versus Java. You may follow along with my examples using the Kotlin Playground or a Java compiler for a more hands-on learning approach.

class Example {}

// extension function declaration
fun Example.printHelloWorld() { println("Hello World!") }

// extension function usage
Example().printHelloWorld()

fun example(a: Any) {
  if (a is String) {
    println(a.length) // automatic cast to String
  }
}

// unsafe "as" cast throws exceptions
val a: String = b as String
// safe "as?" cast returns null on failure
val c: String? = d as? String

if (firstExpression) { // if/else
  variable = secondExpression;
} else {
  variable = thirdExpression;
}

// ternary operator
variable = (firstExpression) ? secondExpression : thirdExpression;

int i = 10;
long l = i; // first widening conversion: int to long
float f = l; // second widening conversion: long to float

There is one topic I’ve intentionally excluded from this table: null safety in Kotlin versus Java. This topic warrants a more detailed Kotlin to Java comparison.

Kotlin vs. Java: Null Safety

In my opinion, non-nullability is one of the greatest Kotlin features. This feature saves time because developers don’t have to handle NullPointerExceptions (which are RuntimeExceptions).

In Java, by default, you can assign a null value to any variable:

String x = null;
// Running this code throws a NullPointerException
try {
    System.out.println("First character: " + x.charAt(0));
} catch (NullPointerException e) {
    System.out.println("NullPointerException thrown!");
}

In Kotlin, on the other hand, we have two options, making a variable nullable or non-nullable:

var nonNullableNumber: Int = 1

// This line throws a compile-time error because you can't assign a null value
nonNullableNumber = null

var nullableNumber: Int? = 2

// This line does not throw an error since we used a nullable variable
nullableNumber = null

I use non-nullable variables by default, and minimize the use of nullable variables for best practices; these Kotlin versus Java examples are meant to demonstrate differences in the languages. Kotlin beginners should avoid the trap of setting variables to be nullable without a purpose (this can also happen when you convert Java code to Kotlin).

However, there are a few cases where you would use nullable variables in Kotlin:

val list: List<Int> = listOf(1,2,3)
val searchResultItem = list.firstOrNull { it == 0 }
searchResultItem?.let { 
  // Item found, do something 
} ?: run { 
  // Item not found, do something
}

lateinit var text: String

fun runtimeFunction() { // e.g., Android onCreate
  text = "First text set"
  // After this, the variable can be used
}

I was guilty of overusing lateinit variables when I first got started with Kotlin. Eventually, I stopped using them almost completely, except when defining view bindings and variable injections in Android:

@Inject // With the Hilt library, this is initialized automatically
lateinit var manager: SomeManager

lateinit var viewBinding: ViewBinding

fun onCreate() { // i.e., Android onCreate

  binding = ActivityMainBinding.inflate(layoutInflater, parentView, true)
  // ...
}

On the whole, null safety in Kotlin provides added flexibility and an improved developer experience compared to Java.

Shared Feature Differences: Moving Between Java and Kotlin

While each language has unique features, Kotlin and Java share many features too, and it is necessary to understand their peculiarities in order to transition between the two languages. Let’s examine four common concepts that operate differently in Kotlin and Java:

public record Employee(
  int id,
  String firstName,
  String lastName
) 

data class Employee(
  val id: Int,
  val firstName: String,
  val lastName: String
) 

ArrayList<Integer> ints =
  new ArrayList<>();
ints.add(5);
ints.add(9);
ints.forEach( (i) ->
  { System.out.println(i); } );

var p: List<String> =
  listOf("firstPhrase", "secondPhrase")
val isShorter = { s1: String,
  s2: String -> s1.length < s2.length }
println(isShorter(p.first(), p.last()))

class Example {
    static void f() {/*...*/}
 }

class Example {
    companion object {
        fun f() {/*...*/}
    }
}

Of course, Kotlin and Java also have varying syntaxes. Discussing every syntax difference is beyond our scope, but a consideration of loops should give you an idea of the overall situation:

for (int i=0; i<=5; i++) {
  System.out.println("printed 6 times");
}

for (i in 0..5) {
  println("printed 6 times")
}

for (int i=0; i<5; i++) {
  System.out.println("printed 5 times");
}

for (i in 0 until 5) {
  println("printed 5 times")
}

List<String> list = Arrays.asList("first", "second");

for (String value: list) {
  System.out.println(value);
}

var list: List<String> =
  listOf("first", "second")

list.forEach {
  println(it)
}

int i = 5;
while (i > 0) {
  System.out.println("printed 5 times");
  i--;
}

var i = 5
while (i > 0) {
  println("printed 5 times")
  i--
}

An in-depth understanding of Kotlin features will assist in transitions between Kotlin and Java.

Android Project Planning: Additional Considerations

We’ve examined many important factors to think about when deciding between Kotlin and Java in a general-purpose context. However, no Kotlin versus Java analysis is complete without addressing the elephant in the room: Android. Are you making an Android application from scratch and wondering if you should use Java or Kotlin? Choose Kotlin, Google’s preferred Android language, without a doubt.

However, this question is moot for existing Android applications. In my experience across a wide range of clients, the two more important questions are: How are you treating tech debt? and How are you taking care of your developer experience (DX)?

So, how are you treating tech debt? If your Android app is using Java in 2022, your company is likely pushing for new features instead of dealing with tech debt. It’s understandable. The market is competitive and demands a fast turnaround cycle for app updates. But tech debt has a hidden effect: It causes increased costs with each update because engineers have to work around unstable code that is challenging to refactor. Companies can easily enter a never-ending cycle of tech debt and cost. It may be worth pausing and investing in long-term solutions, even if this means large-scale code refactors or updating your codebase to use a modern language like Kotlin.

And how are you taking care of your developers through DX? Developers require support across all levels of their careers:

• Junior developers benefit from proper resources.
• Mid-level developers grow through opportunities to lead and teach.
• Senior developers require the power to architect and implement beautiful code.

Attention to DX for senior developers is especially important since their expertise trickles down and affects all engineers. Senior developers love to learn and experiment with the latest technologies. Keeping up with newer trends and language releases will allow your team members to reach their greatest potential. This is important regardless of the team’s language choice, though different languages have varying timelines: With young languages like Kotlin, an engineer working on legacy code can fall behind trends in less than one year; with mature languages like Java, it will take longer.

Kotlin and Java: Two Powerful Languages

While Java has a wide range of applications, Kotlin has undeniably stolen its thunder as the preferred language for the development of new Android apps. Google has put all of its efforts into Kotlin, and its new technologies are Kotlin-first. Developers of existing apps might consider integrating Kotlin into any new code—IntelliJ comes with an automatic Java to Kotlin tool—and should examine factors that reach beyond our initial question of language choice.

The editorial team of the Toptal Engineering Blog extends its gratitude to Thomas Wuillemin for reviewing the code samples and other technical content presented in this article.

Further Reading on the Toptal Engineering Blog: