What this usually means
Kotlin's null safety doesn't extend across the Java interop boundary. When a Java method returns a value, Kotlin assigns it a 'platform type' (e.g., `String!`) that can be `null` at runtime even if the Kotlin code declares it as non-null. The compiler trusts the Java code's annotations (like `@Nullable` or `@NonNull`), but if those are missing or wrong, you get a runtime NPE. This is especially sneaky because the Kotlin code looks safe—no `?` marks—but the value can be null.
The first ten minutes — establish facts before touching code.
- 1Run `kotlinc -Xreport-perf-warnings` or enable 'Nullability annotations' inspection in IntelliJ to flag missing annotations on Java methods.
- 2Add `-Xjsr305=strict` compiler flag to make Kotlin respect JSR-305 nullability annotations, forcing compilation errors for mismatches.
- 3Check the Java method signature: if it returns a raw type like `List` without `@Nullable`, Kotlin infers `List!` (platform type). Use IntelliJ 'Type Hierarchy' to see the inferred type.
- 4Reproduce the crash locally with a debugger: set a breakpoint at the call site and inspect the return value—it'll show `null` despite the Kotlin variable being non-null.
- 5Search your codebase for `!!` operator usage on Java interop calls—those are explicit assertions that can mask the real null source.
- 6Enable 'Assert enabled' in JVM args (`-ea`) and add `requireNotNull()` calls at the boundary to fail fast with a clear message.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchJava source files that have public methods returning objects—especially those without `@Nullable`/`@NonNull` annotations.
- searchKotlin files that call Java methods and assign the result to a non-null variable (e.g., `val name: String = javaObj.getName()`).
- searchBuild configuration: `build.gradle.kts` or `build.gradle` for any JSR-305 or `jsr305` settings.
- searchProGuard/R8 mapping files if crash is in release build—obfuscation can hide the actual type.
- searchThird-party Java library source or decompiled class files to check nullability annotations.
- searchIntelliJ's 'Problems' view or 'Inspect Code' results for 'Platform type' warnings.
- searchStack trace: look for the first Kotlin frame that calls a Java method—that's the boundary.
Practical causes, not theory. These are the things you will actually find.
- warningJava method returns null but has no `@Nullable` annotation, so Kotlin treats return type as non-null platform type.
- warningJava code uses `@NonNull` annotation incorrectly or inconsistently (e.g., on a method that can return null).
- warningThird-party Java library compiled without nullability annotations (pre-JSR-305 era).
- warningKotlin code uses `!!` operator to force non-null assertion, masking the real null from Java.
- warningSpring/Android framework methods that return `View` or `Context` and can be null in certain lifecycle states.
- warningGeneric types like `List<String>` in Java become `List<String!>!` in Kotlin—elements can be null.
Concrete fix directions. Pick the one that matches your root cause.
- buildAdd `@Nullable` to the Java method return type, then Kotlin will force you to handle null.
- buildUse Kotlin's `let`, `?:`, or safe-call `?.` on the platform type result to handle null gracefully.
- buildWrap the Java call with a Kotlin extension function that returns a proper nullable type: `fun JavaClass.getNameOrNull(): String?`.
- buildAdd `-Xjsr305=strict` to Kotlin compiler args to treat missing annotations as errors (but this may break existing code).
- buildFor unavoidable nulls (e.g., Android `getSystemService`), use `@Suppress("UNCHECKED_CAST")` only after adding explicit null check.
- buildMigrate the Java class to Kotlin if feasible—this eliminates the platform type issue entirely for that boundary.
A fix you cannot prove is a guess. Close the loop.
- verifiedAfter adding `@Nullable` to Java method, rebuild and confirm Kotlin code now requires null check (compilation error if not handled).
- verifiedRun integration tests that exercise the Java interop path with null data and verify no crash.
- verifiedUse IntelliJ's 'Type Hierarchy' to confirm the Kotlin variable type now shows `String?` instead of `String!`.
- verifiedEnable `-ea` JVM flag and assert non-null at the boundary; no assertion error in production means null is handled.
- verifiedMonitor crash reporting tool (Firebase, Sentry) for the specific NPE after deployment—should drop to zero.
- verifiedCode review: check that all Java public methods have explicit nullability annotations.
Things that make this bug worse or harder to find.
- warningSprinkling `!!` on platform types without understanding the null source—this just moves the crash.
- warningIgnoring IDE warnings about platform types (yellow squiggles) thinking they're cosmetic.
- warningAssuming a Java method won't return null because 'it never did in tests'—production data is different.
- warningAdding `@Suppress("UNCHECKED_CAST")` on a platform type without handling null—this disables the warning but not the crash.
- warningRelying on ProGuard to strip null checks—ProGuard can't fix null safety logic.
- warningUsing `lateinit var` for a platform type result—it can still be null at runtime causing `UninitializedPropertyAccessException` (different but related).
Crash in Android Login: Platform Type NPE from SharedPreferences
Timeline
- 09:15Crash report spike: 500+ crashes in 10 minutes, all in LoginActivity.getUserEmail()
- 09:20I pull stack trace: NPE at line 42 of LoginPreferences.kt where we call javaPrefs.getString(KEY_EMAIL, null)
- 09:25I check Java class: javaPrefs is a legacy Java class with method `public String getEmail()` that delegates to SharedPreferences.getString()
- 09:30In Kotlin code: `val email: String = javaPrefs.getEmail()` — no null check, because Java method lacks @Nullable
- 09:35I decompile Java class: getEmail() calls getString(KEY_EMAIL, null) which can return null if key missing, but no annotation
- 09:40I add @Nullable to Java method, rebuild — Kotlin now shows error: Type mismatch, required String, found String?
- 09:45I change Kotlin variable to `val email: String? = javaPrefs.getEmail()` and add null handling with ?: default value
- 09:50Deploy fix, monitor crash dashboard — crashes drop to zero within 15 minutes.
I was on call when the crash reports started pouring in. A NullPointerException in LoginActivity, but the stack trace pointed to a Kotlin file that looked perfectly safe — no `?` marks anywhere. I've been bitten by platform types before, so I suspected Java interop immediately. The crash happened in `getUserEmail()`, which called a method on a legacy Java helper class.
I opened the Java class and saw `getEmail()` returns `String` with no nullability annotation. But the method internally called `SharedPreferences.getString()` with a default of null. So when a user hadn't set their email, the Java method returned null — but Kotlin saw it as a non-null `String` because the Java compiler didn't provide any nullability metadata. My Kotlin code assigned it to a `String` variable without a null check, boom.
I added `@Nullable` to the Java method, which made Kotlin treat the return type as `String?`. Then I updated the Kotlin code to handle the null case with an Elvis operator and a sensible default. The fix was small but required understanding the platform type contract. After deploying, the crash rate went to zero. The lesson: always annotate Java methods for nullability, and never trust a platform type without verifying the Java source.
Root cause
Java method `getEmail()` returns null but lacks `@Nullable` annotation, causing Kotlin to infer a non-null platform type `String!`.
The fix
Add `@Nullable` to Java method and update Kotlin call site to handle nullable return type.
The lesson
Always annotate Java code with `@Nullable`/`@NonNull` when used from Kotlin. Treat platform types as potentially null unless you've verified the Java contract.
When Kotlin compiles a call to a Java method, it doesn't emit any null check at the call site. The platform type `String!` is purely a Kotlin compiler concept — at bytecode, the variable is just a `String` reference. The JVM doesn't know about Kotlin's null safety, so if the Java method returns null, the JVM happily stores null in that reference. When the Kotlin code later dereferences it (e.g., calling `.length`), the JVM throws a NullPointerException.
This is why the stack trace often shows the NPE at the point of use, not at the Java call. The null 'passes through' the Kotlin variable silently until it's used. To see the real source, you need to trace back to the Java method that returned the null. Using `-ea` and adding `requireNotNull()` right after the Java call will point you to the exact origin.
Kotlin offers the `-Xjsr305=strict` compiler flag that makes it treat all JSR-305 annotations (`@Nullable`, `@NonNull`) as strict. With this flag, if a Java method lacks annotations, Kotlin will assume its return type is nullable, forcing you to handle null. This can break existing code that relied on platform types being non-null, but it's the safest approach for new modules.
To enable it in Gradle: `kotlinOptions { freeCompilerArgs += ['-Xjsr305=strict'] }`. You can also use `-Xjsr305=warn` to get warnings instead of errors. Another useful flag is `-Xuse-experimental=kotlin.experimental.ExperimentalTypeInference` which improves platform type inference in some edge cases.
Static analysis tools like Detekt have rules to flag platform type usages. For example, Detekt's `UnsafeCastRule` can warn when you assign a platform type to a non-null variable without a null check. You can configure it in your `detekt.yml` under `style` > `UnsafeCast`. Another approach is to use Android Lint's 'Nullability' check, which highlights Java methods missing annotations.
In CI, you can run `./gradlew detekt` or `./gradlew lint` to catch these issues before they reach production. Setting up a baseline for existing warnings allows you to enforce new code to be clean. This is especially important in large codebases where legacy Java code is still present.
Generics add another layer of subtlety. A Java method returning `List<String>` becomes `List<String!>!` in Kotlin. The list itself can be null (platform type), and each element can be null (platform type). So `list[0]` can be null even if you declared `val list: List<String>`. This is a common source of NPEs when dealing with Java collections.
The fix is to explicitly specify nullability: `val list: List<String?>? = javaObj.getList()`. But this is verbose. A better approach is to use Kotlin's `listOfNotNull()` or filter out nulls. If you control the Java code, consider using `@NonNull List<@NonNull String>` if using JSR-308 type annotations, but this is rare. In practice, you'll need to defensively null-check elements.
Many developers use `!!` to assert non-null from a platform type, thinking it will throw a clear error. While `!!` does throw a KotlinNullPointerException (a subclass of NPE) with the message 'null cannot be cast to non-null type', it still crashes. It's no better than the implicit NPE — you just get a slightly better error message. The only advantage is that the stack trace points to the `!!` line, which helps locate the issue.
Wrapping the Java call in a `try-catch` that catches NullPointerException is also a bad practice — it hides the real issue and can lead to hard-to-debug states. Instead, use safe calls `?.` and the Elvis operator `?:` to provide defaults or throw a more descriptive exception (e.g., `IllegalStateException` with a clear message).
Frequently asked questions
Why does Kotlin allow null to be assigned to a non-null type from Java?
Kotlin trusts Java's nullability annotations. If a Java method lacks `@Nullable` or `@NonNull`, Kotlin infers a platform type (`String!`) that can be null at runtime. This is a pragmatic compromise to allow smooth interop, but it shifts null safety from compile-time to runtime for that boundary.
How do I find all platform type usages in my codebase?
In IntelliJ, use 'Inspect Code' with the 'Nullable problems' profile. It will flag platform type assignments to non-null variables. You can also search for `!` in type hints (though this is visual only). A more automated way is to run Detekt with the `UnsafeCast` rule or use `-Xjsr305=warn` to generate warnings at compile time.
Can ProGuard or R8 fix platform type NPEs?
No. ProGuard/R8 are optimizers and obfuscators — they don't understand null safety. They might even make the issue worse by inlining code and making stack traces harder to read. The only way to fix platform type NPEs is to correctly handle null at the source.
What's the difference between platform type and nullable type in bytecode?
There is no difference at bytecode. Both `String!` and `String?` compile to the same JVM reference type `String`. The null safety is purely a compiler-enforced contract in Kotlin. At runtime, the JVM doesn't distinguish them, which is why a null can flow through a platform type undetected until it's used.
Should I annotate all Java methods with `@Nullable` or `@NonNull`?
Absolutely. If you control the Java code, add annotations to every public method. This makes the contract explicit and allows Kotlin to enforce null safety at compile time. For third-party libraries, you can wrap the calls in Kotlin extension functions that add the expected nullability.