- Background -
When trying to determine why a specific class isn't loading, or why you got the wrong version of a class, it can be difficult to untangle the maze of classloaders to determine what classloaders tried to load your class, in what order, and where they tried to load it from. A number of StackOverflow posts (and messages on other forums) have questions that center around the lack of this data.

Some of this information can be got from the debug options already in place, such as Class.getClassLoader(), and -verbose:class.

However, that doesn't give you the entire picture. Information we can't get includes:

- Which ClassLoader/s *tried* to load that class, and in which order.
- What each ClassLoaders' classpath was.
- What happened when each ClassLoader tried to access each location on its classpath.
- How each ClassLoader tried to load the class (e.g. classpath vs modules).
- Which modules were checked.
- etc, etc.

- Proposed Solution -

One solution is to add a system property to OpenJDK that triggers detailed debug output when ClassLoaders (other than the BootClassLoader, to avoid potential problems) try to load the class listed in the property. Perhaps some form of regular expression would be best, as that allows more flexibility.

- Potential Risks -

@ That the debug code will slow down the ClassLoader when the debug option is not specified.
Addressed by locking every line of debug code behind an IF statement using a static final boolean, allowing the JIT to compile it into oblivion if the debug variable is not in use.

@ That the verbose output will drown the user in information they can't use, via irrelevance or over-complexity.
Addressed by using event-specific methods that use nontechnical terminology. Also, output is limited by matching on the class name.

@ That System.println will dump information on the user when we'd rather have it directed elsewhere (e.g. a log file) without having to redirect all stdout.
Addressed by use of a stream variable. It outputs to System.out by default, but could be modified easily if needed.

@ That loading a class from a module will confuse the output.
Addressed by the use of dedicated helper message methods to properly handle module wrangling.

- Concept Webrev -

http://cr.openjdk.java.net/~afarley/8232773/webrev/

- How to use -

Simply add "-Djdk.cl.verbose=*TestClass" to your command line, and any class whose full id ends in "TestClass" will have information about the process that loaded it piped to the screen.

- Example -
java -Djdk.cl.verbose=*TestClass -cp /test/class/location TestClass
AppClassLoader was asked to load TestClass
AppClassLoader is attempting to find TestClass
AppClassLoader will now ask its parent ClassLoader (PlatformClassLoader) to find TestClass
PlatformClassLoader was asked to load TestClass
PlatformClassLoader is attempting to find TestClass
PlatformClassLoader will now ask its parent ClassLoader (BootClassLoader) to find TestClass
PlatformClassLoader recently asked its parent ClassLoader (BootClassLoader) to find TestClass
PlatformClassLoader has been informed that its parent was not successful
AppClassLoader recently asked its parent ClassLoader (PlatformClassLoader) to find TestClass
AppClassLoader has been informed that its parent was not successful
AppClassLoader will search for TestClass on the classpath
AppClassLoader is using this classpath: /test/class/location
AppClassLoader found TestClass.class in /test/class/location
AppClassLoader found TestClass