[kodeninja]

Probably unrelated, but Java really needs to fix its Classpath Hell issues. On so many sufficiently large Java projects, you end up descending into the inclusion/exclusion madness with your build files because your app is inheriting `log4j` from 50 different libraries. Or the infamous xerces hell[1]. And fixing that in maven is not pretty :(.

[1] https://stackoverflow.com/questions/11677572/dealing-with-xe...

[foobarchu]

I hit this just recently with an in-house dependency injection library. We upgraded the version in an application, it worked great, we deployed it to a cloud environment. Lo and behold the application wouldn't start up, and more importantly wouldn't give us a real reason why. In the end I discerned from cryptic logs that it was because Java had loaded up both the jar of the version we wanted and the jar of an older version that happened to be in the classpath too. You can't have two dependency injection systems running at the same time, so they fought and came to a stalemate. Deleted the bad version and it was all good.

I know that this isn't entirely Java's fault, as that second jar shouldn't have been there to begin with, but it's pretty ridiculous that two versions of the same dependency can be loaded and in use at the same time.

[jryan49]

Wasn't Java 9 modules supposed to help address these issues?

[aiCeivi9]

No, it is supposed to reduce surface area between modules/jars. Before Java9 library creators could only add "internal" to their packages name and hope end users won't touch it.

The introduction of modules might actually make version hell even worse: https://blog.codefx.org/java/dev/will-there-be-module-hell/