Anyone else noticing Claude Code's weird obsession with Java? I'm working in a Kotlin codebase, and it keeps defaulting to Java idioms and solutions even when I'm clearly asking about Kotlin files. It's like it sees JVM and its brain short-circuits to the most verbose option possible.
Here's what keeps happening:
* I'll paste a Kotlin data class and ask for an extension function. It gives me a Java static method.
* I'll ask about coroutine usage in a service layer, and it starts explaining `CompletableFuture`.
* I'll request a refactor to use sealed classes, and it provides a Java enum with a switch statement.
This isn't a minor style nitpick. The value propositions for Kotlin are conciseness, null safety, and functional constructs. Getting Java solutions defeats the entire purpose of using the language.
I've tried:
* Explicitly stating "in Kotlin" in every prompt.
* Setting a project context at the start of the session.
* Even adding "// Kotlin" comments in the code block.
The results are inconsistent at best. It feels like the underlying model has a strong Java bias that overrides the context. For a tool marketed for "Code," this is a pretty significant blind spot when dealing with a major JVM language.
Is this a configuration issue on my end, or are others in mixed JVM environments seeing the same thing? More importantly, has anyone found a reliable way to keep it on track? I'm not paying for a fancy Java code generator.
Trust but verify.
Oh, I've definitely seen this pattern with other JVM languages, especially with older codebases that have a lot of Java history. Your point about the value proposition being defeated is spot-on - suggesting a Java enum for a Kotlin sealed class is a fundamental misunderstanding of the language's intent.
One thing that's given me slightly better results is being extremely prescriptive in the prompt about what *not* to do. Something like "Provide a Kotlin-specific solution. Do not use Java syntax, idioms, or standard library classes like CompletableFuture." It's frustrating to have to babysit the context that way, though.
The inconsistency is the real killer. It suggests the model's training data might be heavily weighted toward Java for anything JVM-related, and it can't fully suppress that bias even when explicitly told otherwise. Have you tried reporting these specific examples through the feedback channels? Sometimes pattern-based issues get flagged for retraining faster if they have clear, repeated examples.
Keep it constructive.
Yeah, the "explicitly tell it what not to do" tip is huge. It's like training a dog sometimes haha. I've found I also have to specify the Kotlin standard library, like "use `kotlinx.coroutines`" or it'll still sneak in Java concurrency stuff.
Do you think the bias is worse in mixed Java/Kotlin projects? I'm working on a greenfield Kotlin service and still get Java suggestions, so maybe it's just the JVM tag that triggers it.