Is there a way to determine which classes are loaded from which JARs at runtime?
I'm sure we've all been in JAR hell before. I've run across this problem a lot troubleshooting ClassNotFoundException
s and NoClassDefFoundError
s on projects. I'd like to avoid finding all instances of a class in JARs and using process of elimination on the code causing a CNFE to find the culprit.
Will any profiling or management tools give you this kind of information?
This problem is super annoying purely because we should have this information at the time the class gets loaded. There has to be a way to get to it, or record it and find it, yet I know of nothing that will do this, do you?
I know OSGi and versioned bundles/modules aim to make this a non issue... but it doesn't seem to be going away any time soon.
Note: I found this question is a subset of my question related to classes loaded from versioned jars.
Somewhat related, this post explains a strategy to search for a class within JARs (either under the current directory) or in your M2_REPO: JarScan, scan all JAR files in all subfolders for specific class
Also somewhat related, JBoss Tattletale
The, the idea is to use find on the root of your classpath to locate all jars, then runs findclass.sh on all found jars to look for a match. It doesn't handle multi-directories, but if you carefully choose the root you can get it to work.
this is a very simple and useful tool for windows. A simple exe file you click on, give it a directory to search in, a class name and it will find the jar file that contains that class.
There are few ways to do this. Use –verbose:class flag with your java command line. This option enables loading and unloading of classes. It shows the jar file from which the class is loaded.
5. Which class loader loads jar files from JDK directory? Explanation: Extension loads jar files from lib/ext directory of the JRE. This gives the basic functionality available.
Passing the -verbose:class
switch to the java
command will print each class loaded and where it was loaded from.
Joops is also a nice tool for finding missing classes ahead of time.
From code you can call:
myObject.getClass().getProtectionDomain().getCodeSource()
(Note, getProtectionDomain
may unfortunately return null
(bad design), so "proper code" would check for that.)
There is an MBean for the JVM flag mentioned by Jason Day above.
If you are using JBoss, you can twiddle this on demand using JMX, if you add the native JMX MBean server to your config. Add the following -D's:
-Dcom.sun.management.jmxremote.port=3333
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djboss.platform.mbeanserver
-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl
-DJBOSS_CLASSPATH="../lib/jboss-system-jmx.jar"
And then you can see this setting under the java.lang:Classloading MBean and can cut it on/off on the fly. This is helpful if you only want it on while executing a certain piece of code.
There is also an MBean which will allow you to enter a fully qualified classname and see where it was loaded from in the class hierarchy. The MBean is called LoaderRepository and you'll want to invoke the displayClassInfo() operation, passing in the FQCN.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With