Calling Java From Kotlin

List has no add or remove methods, MutableList does. But it's only a rule the compiler checks. At runtime both are usually the same Java ArrayList, so the read-only promise can be broken from Java code.

Kotlin lets you write obj.name instead of obj.getName(). It turns Java get/set methods into a property you read and write with a dot. You can still call obj.getName() the old way too.

You call them directly on the class name, just like in Java: Integer.parseInt("42") and Integer.MAX_VALUE. There is no special import or wrapper needed.

A platform type is a value coming from Java whose nullability Kotlin can't know. The compiler relaxes null checks for it. If you treat it as non-null but it's actually null, you get a NullPointerException at runtime.

A SAM conversion lets you pass a short Kotlin lambda where Java expects an interface with exactly one method, like Runnable or Comparator. Kotlin turns the lambda into that interface automatically, so you skip the boilerplate anonymous class.

Use the spread operator: put * before the array, like foo(*arr). It unpacks the array so each element is passed as a separate vararg argument instead of one array argument.

It usually shows up as a MutableList, so Kotlin lets you add and remove from it. But Java may not expect that list to change, so calling add could throw or corrupt the caller's data.

Nothing is forced. Kotlin has no checked exceptions, so the compiler does not make you write try/catch or declare the exception. You may catch it if you want, but you don't have to.

If the Java code is annotated with @Nullable or @NotNull, Kotlin stops treating the value as a loose platform type and treats it as String? or String. Kotlin recognizes several common annotation libraries like JetBrains, JSR-305, and AndroidX.

By default Kotlin only auto-converts lambdas for Java single-method interfaces. For a Kotlin interface you mark it 'fun interface'. Without that, you must write a full object expression implementing the interface.

Invariant means Array<String> is NOT a subtype of Array<Any>, even though String is a subtype of Any. Java arrays are covariant (String[] is an Object[]), which can blow up at runtime; Kotlin blocks that at compile time.

Upcasting just changes the reference type but keeps the same object, so changes still leak through. toList() makes a brand-new copy, so later changes to the original don't affect it. Use toList() when you need a stable, independent snapshot.

Kotlin sees it as a property called enabled — but wait, no: for is-prefixed getters Kotlin keeps the whole name. The property is isEnabled, accessed as obj.isEnabled, and set via setEnabled.

Only methods shaped exactly like JavaBeans accessors become properties. A getter with parameters, a void/Unit getter, or a wrong name (like fetchName) stays a plain method. If getter and setter types disagree, you only get a read-only property.

You access a public Java field directly by name: obj.count to read and obj.count = 5 to write. It looks just like a Kotlin property even though Java has no getter or setter.

A SAM constructor wraps a lambda into a specific interface by writing the interface name before the lambda, like Runnable { ... }. You use it when the target type is ambiguous — for overloads, generics, or storing the value in a variable.

run(*arr) compiles and spreads the array's elements. run(arr) does not compile because an Array<String> isn't a String. Each spread makes a defensive copy of the array, so spreading in a loop allocates repeatedly.

Yes. Kotlin's read-only List is just a java.util.List to Java, so Java sees the normal add and remove methods and can change the list, even though Kotlin marked the parameter as read-only.

In Kotlin you can override the inherited Java accessor pair as a property — declare override var value and supply custom get()/set(). You may also still override the raw methods, but using the property form is the idiomatic way.

Because Kotlin doesn't record a throws clause in the compiled method, Java thinks the exception can't happen and refuses to let you catch it. Adding @Throws puts the clause back so Java can catch it.

Wrap the Java library behind a thin Kotlin layer. At that boundary, give every value an explicit nullable or non-null type and validate it, so the rest of your code only ever sees proper Kotlin types and never raw platform types.

JSpecify is a standard, vendor-neutral set of nullability annotations for Java. Kotlin understands it, including module-wide defaults and generic type-argument nullability, and can treat any mismatch as a compile error in strict mode.

Each SAM-converted lambda may become a different object instance, so you can't reliably remove a listener by passing the 'same' lambda again. Capture the converted instance in a variable and reuse that exact reference for both add and remove.

SAM conversion needs a Java interface with exactly one abstract method as the target. It won't fire for abstract classes, multi-method interfaces, plain Kotlin interfaces, or when the parameter is already a Kotlin function type. A function type passed to Java surfaces as a FunctionN object, not your interface.

Kotlin sees the Java arrays as platform types with unknown nullability (shown like Array<Any!>! and IntArray!). The primitive int[] becomes IntArray; the Object[] becomes Array<(out) Any!>. You decide the nullability and must pass IntArray, not Array<Int>.

A plain Kotlin read-only List isn't enough because Java can still change it. Use a defensive copy wrapped so mutation throws, or a truly immutable collection type whose add/remove always fail for everyone.

Pitfalls include both getName() and isName() existing (ambiguity), names like getURL decapitalizing oddly, and confusion when going the other way: Kotlin properties appear to Java as getX()/setX() methods, so Java callers never see a 'property'.

Since the compiler won't force you, you have to be disciplined: catch failures where you can act on them, model expected errors as return values (like a Result or sealed type), and document or annotate what each boundary can throw.

When you override a Java method in Kotlin, you must pick a concrete nullability — nullable or non-null — for the return and parameters; you can't leave it as a platform type. With generics, Kotlin substitutes the platform nullability into the type argument the same way.