上QQ阅读APP看书，第一时间看更新

Language runtime libraries

This is somewhat related to building complications. Many alternative JVM languages require their own support libraries to be bundled with the compiled program. These libraries often define data structures that are unique to the language and internal support methods that the language's compiled Java bytecode calls.

This is usually not a problem, but things can get problematic if one of the project's dependencies (or one of the project's dependencies' dependencies...) is compiled in the same language but of a different version. Things can get messy when a different version of the same runtime library is required by multiple libraries of the same project and can result in confusing error messages when compiling or running the project.

This situation is called dependency hell and is not really specific to the usage of multiple languages in a single project, but it is something every developer should be aware of. Developers that want to mix languages should also be aware of the fact that sometimes language runtime libraries increase the final size significantly and that some runtime libraries also bundle their own dependencies; this increases the risk of dependency-hell-like problems. Often, dependencies are documented in the language's documentation or website.

Many language developers, like many framework designers, are aware of these problems and have taken steps to minimize the risks of these problems. For example, they commonly fork the more popular dependencies they use themselves and rename them to prevent class name clashes.