liveBook · Manning

Platform type

As explained in Kotlin in Action, 2E

A platform type is a Kotlin type imported from Java when the Java declaration provides no nullability information, leaving Kotlin unable to determine whether its value is nullable.

A platform type is a Java type whose nullability annotations are absent, so Kotlin cannot determine whether values may be null. Kotlin lets you use the value as either nullable or non-nullable, preserving interoperability while making you responsible for safe operations. section 7.12 section 7.12.1

Choose how to handle an unannotated Java property

A Java class declares `String getName()` without nullability information. Kotlin can dereference the result directly: `fun yellAt(person: Person) { println(person.name.uppercase() + "!!!") }` If `name` is null, this fails at the usage site with a `NullPointerException`. Treating the result as nullable is safer: `fun yellAtSafe(person: Person) { println((person.name ?: "Anyone").uppercase() + "!!!") }` The compiler also accepts either assignment: `val s: String? = person.name` or `val s1: String = person.name`. IDE inlay hints may display the platform type with an exclamation mark. section 7.12.1

When consuming Java APIs, make the missing contracts explicit:

  • Check Java documentation and, when necessary, implementation code to determine whether a returned value can be null. section 7.12.1
  • Use a null check or nullable type when the value may be absent; use direct access only when non-null behavior is known. section 7.12.1
  • When implementing Java methods, choose parameter nullability deliberately; Kotlin can override a Java `String` parameter with either `String` or `String?`. section 7.12.2
  • For Java collections, decide independently whether the collection, its elements, and its mutability are nullable or mutable. section 8.2.4
Figure 7.10 Java types without special annotations are represented in Kotlin as platform types. You can choose to use them either as nullable or non-nullable types.
CH07_F10_Isakova

Use the figure to compare annotated Java types, which become explicitly nullable or non-nullable in Kotlin, with unannotated types, which remain platform types. section 7.12.1

How Kotlin in Action, 2E covers it

How deep it goes
Explains nullable and non-nullable use, runtime failure, IDE notation, inheritance, and collection mutability, but not compiler implementation internals.
Examples
Uses an unannotated Java Person, unsafe and safe name access, Java interface overrides, and collection-processing interfaces.
What it assumes
Assumes familiarity with Kotlin nullability and Java declarations while teaching the consequences of absent annotations through compact examples.
What you can do after
Apply it by inspecting Java APIs and selecting explicit Kotlin nullability and mutability contracts at interoperability boundaries.
How it connects
Connects Java interoperability with nullability, safe calls, the Elvis operator, inheritance, generics, and mutable or read-only collections.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kotlin in Action, 2E. The section links point to the parts of the book it draws on.