Call Java APIs and inspect platform types

Kotlin/JVM code can use many existing Java libraries. This makes integration practical, but Java APIs may not provide Kotlin’s full nullability information. A platform type reflects that uncertainty and needs appropriate boundary handling.

Import a Java class and call its supported API with Kotlin syntax. Kotlin properties can map to Java accessor patterns. An unannotated Java reference may be seen as a platform type, which should not be treated as evidence that a value can never be null.

Connect this to nullable types and safe calls and sets, pairs and destructuring.

Save the complete source as Main.kt and use the Kotlin/JVM environment. No separate input file is needed.

Kotlin/JVM · complete program

import java.util.TreeSet
fun main() {
  val names = TreeSet<String>()
  names.add("Saira")
  names.add("Diya")
  println(names.joinToString(", "))
}

Expected output

Diya, Saira

Follow the execution

TreeSet applies its ordering contract, so Diya appears before Saira regardless of insertion order. This is an explicit Java collection choice, not a guarantee that every Kotlin set displays alphabetically.

Try this in the Kotlin compiler by pasting the complete program.

Your task: Can you assume an unannotated Java return value is never null?

Kotlin/JVM · complete program

import java.util.TreeSet
fun main() {
  val names = TreeSet<String>()
  names.add("Saira")
  names.add("Diya")
  println(names.joinToString(", "))
}

Worked answer

No. Inspect its documented contract and validate or choose a nullable boundary representation where necessary.

Nullability annotations improve the contract but do not prove all external implementations obey it. Named arguments, checked exceptions, arrays and static members have interop-specific details. Use official guidance for a real library boundary.

No. Inspect its documented contract and validate or choose a nullable boundary representation where necessary. Nullability annotations improve the contract but do not prove all external implementations obey it.

Further reading: official Kotlin documentation for this topic.