Software Engineering
Kotlin-Java cross-language interactions breed bugs and defects, study reveals
A new empirical study of 40 real-world projects identifies ten common issues that emerge when Kotlin and Java code interact, along with tools to detect them proactively.
Kotlin's rise as an official Android development language since 2017 has led many projects to blend it with existing Java codebases. While the two languages are designed to interoperate seamlessly, little is known about what actually happens when they work together in real systems. A new empirical study sheds light on the practical challenges and hidden costs of mixing these languages.
The scope of the study#
Researchers analyzed 40 Kotlin-Java projects containing roughly 27,000 Java files and 36,000 Kotlin files. They developed DependExtractor, a tool to catalog all dependency relationships between the two languages—identifying 11 types of Kotlin-to-Java interactions and 9 types in the reverse direction.
The investigation focused on understanding how frequently Kotlin and Java code calls and accesses one another, and what problems emerge from these cross-language connections.
Key findings on code interactions#
The study found that Access and Call dependency types dominate cross-language interactions in these projects. Files that participate in interoperability with code in the other language undergo significantly more code changes and suffer from higher defect rates than those that remain isolated within a single language.
This suggests that cross-language boundaries add friction—more commits happen to these boundary files, and bugs accumulate faster when Kotlin and Java components must coordinate.
Ten common issues and detection#
The researchers catalogued ten recurring problem patterns in Kotlin-Java interactions and documented the strategies developers use to fix them. To help teams catch these issues early, they built InteropScan, a tool that scans Java and Kotlin source code to detect these problematic patterns before they reach production.
The work underscores that while language interoperability is a feature, it carries measurable engineering costs that developers should understand and actively manage.