The system class loader loads code found on java.class.path, which maps to the CLASSPATH environment variable.
It is therefore possible to create a custom class loader without understanding the finer details of the Java Virtual Machine.
So-called "servlet containers" are typically implemented in terms of multiple class loaders.
[10] Three ways JAR hell can occur are: The OSGi Alliance specified (starting as JSR 8 in 1998) a modularity framework that aims to solve JAR hell for current and future VMs in ME, SE, and EE that is widely adopted.
It also specifies a repository for storing these collections, or modules, and identifies how they can be discovered, loaded and checked for integrity.
It includes features such as namespaces with the aim of fixing some of the shortcomings in the existing JAR format.
However, since the Java Platform Module System does not offer the ability for controlled co-existence of libraries with different versions, it does not fully address the JAR hell problem.