Lectures

We break down how Kotlin/JVM “gets along” with the JDK: how to import classes from java.*, how using a fully qualified name differs from import, how to call Java constructors and “static” methods (for example, UUID.randomUUID() and System.getProperty(...)), how to work with mutable Java collections ( ArrayList), and which errors are most common in the first attempts to call Java APIs from Kotlin.

We break down what platform types ( T!) are in Kotlin when doing Java interop, why the compiler cannot always guarantee null-safety at the boundary with Java, and how to “ground” values into an explicit contract: T? (nullable + safe handling via ?. and ?:) or T (fail-fast via require or !!). Using practical examples with System.getProperty, System.getenv, and UUID, we show where NPEs hide and how to build a “boundary contract” discipline.

We break down how Kotlin on the JVM “understands” Java-code nullability: when Java signatures get enhanced by @Nullable/ @NotNull annotations, why platform types ( T !) sometimes remain, and how to properly handle collection nullability (container vs elements) via boundary normalization: ?: emptyList (), filterNotNull (), mapNotNull ().

We break down how Kotlin on the JVM “plays nicely” with Java APIs that accept functional interfaces (SAM types, Single Abstract Method): how a lambda is automatically turned into a Runnable, Predicate, or Comparator, how trailing-lambda syntax works, why ambiguous overloads sometimes happen, and which practical mistakes occur most often (overflow in a comparator, confusion between Predicate<T> vs (T) -> Boolean, capturing an outer var).

We break down how Java “sees” Kotlin on the JVM: why top-level functions end up in a class with the Kt suffix, how to give that class a normal name via @file:JvmName, and when it makes sense to export properties as fields without getters/setters using @JvmField. At the end — a mini-embedding into a CLI project and typical interop mistakes.