# Undisclosed bundled dependencies in Kotlin compiler POM metadata

DevFeed: [Undisclosed bundled dependencies in Kotlin compiler POM metadata](<https://devfeed.tech/articles/this-is-why-we-can-t-have-nice-things-when-pom-files-lie-30466.md>)

Original publisher: [Read original article](<https://dev.to/autonomousapps/this-is-why-we-cant-have-nice-things-when-pom-files-lie-3lm5>)

Author: Tony Robalik

Published: 2025-02-07T23:54:47Z

Content type: opinion

Language: en

Sources: [DEV Community: Tony Robalik](<https://devfeed.tech/sources/dev-community-tony-robalik.md>)

Topics: [Dependency management](<https://devfeed.tech/topics/dependency-management.md>), [Java](<https://devfeed.tech/topics/java.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>)

Tags: [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [dependency-management](<https://devfeed.tech/tags/dependency-management.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [java](<https://devfeed.tech/tags/java.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

The author investigates a JVM ClassCastException and traces it to the Kotlin compiler JAR loaded by Gradle. They argue that bundled, unrelocated Guava classes and POM metadata that does not disclose the fat JAR create dependency-management problems.

## Source excerpt

Photo by Marco Bicca on Unsplash. I really hope there's a light at the end of this sewer. Sorry, my country is dissolving into a Nazi sewer of world-historical proportions and so I'm dealing with my otherwise fruitless rage by yelling about JVM things. The fact that Java classes exist in a global namespace is not well-appreciated, even by vendors of major parts of the ecosystem (apparently). Caused by: java.lang.ClassCastException: class com.google.common.graph.ImmutableGraph cannot be cast to class com.google.common.graph.SuccessorsFunction (com.google.common.graph.ImmutableGraph and com.google.common.graph.SuccessorsFunction are in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader @4617120) A confusing error at the best of times, but to a build engineer (i.e. me) trying to help out during a SEV, a despair-inducing example of how Dependency Management on the JVM is Completely Broken, What Are We Even Doing Here. A ClassCastException always means Someone Somewhere Hates You, or at least values their own KPIs more than not polluting the entire goddamn ecosystem. Let's debug! My first step is to navigate to the Graph class and check its hierarchy. I can confirm that, yes, in Guava 33.3.1-jre at least, that class does indeed implement the SuccessorsFunction interface. It should not be throwing a ClassCastException! Next step. In Intellij (the vendor which is ironically the source of this amongst most of the rest of my woes), I set a breakpoint at the exception and evaluate the following expression.1 // `this` is an instance of the `com.google.common.graph.Graph` class this.javaClass.superclass.superclass.superclass.interfaces.first().protectionDomain.codeSource.location That expression resolves to this: file:/Users/<<ME!>>/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler/2.0.21/88f09afc2536e38d528e78eb8349504de10ac436/kotlin-compiler-2.0.21.jar What the fuck! That is not the righ