Skip to main content

Java interoperability corner cases and interviews

Corner cases​

  • Java wildcards may require @JvmSuppressWildcards or @JvmWildcard, but change them only after inspecting the generated signature.
  • Kotlin unsigned types and value classes have specialized JVM interop considerations.
  • Companion methods are not true Java statics without @JvmStatic bridges.
  • Kotlin properties generate accessor methods unless exposed with @JvmField.
  • Java may pass null into Kotlin non-null parameters; Kotlin inserts runtime checks at public boundaries.
  • Java serialization/reflection frameworks may need no-arg constructors, annotations, adapters, or generated code.
  • Kotlin internal visibility is not a strong Java/JVM security boundary.

Interview questions​

What is a platform type?

A Java-origin type whose nullability is unknown to Kotlin. Kotlin permits flexible use, so the developer must normalize it to an explicit nullable or non-null type.

Why use @JvmOverloads?

It generates overloads for trailing default parameters so Java callers can omit them. It should be used deliberately because it expands the JVM API.

How would you migrate a large Java Android app?

Incrementally: annotate boundaries, add Kotlin tooling, use Kotlin for new work, convert tested vertical slices, review Java callers, isolate legacy APIs, and measure build/product outcomes.

Exercises​

  1. Write a Java method with no nullability annotation and consume it safely from Kotlin.
  2. Expose a Kotlin factory cleanly to Java.
  3. Compare a Kotlin function-type callback with a fun interface from Java.
  4. Design an adapter that prevents platform types entering the domain layer.
  5. Create a migration ADR with risks, metrics, and rollback plan.
Interview-ready answer

Kotlin/Java interop is strong, but production quality depends on explicit nullability, Java-friendly API design, exception behavior, generic signatures, generated names, and gradual migration controls.