It’s all described in Tomcat’s ClassLoading HOW-TO. It’s not necessarily in alphabetic order. If you observed that behaviour, it should absolutely not be relied upon if you intend to keep your webapp portable across servers. For example, Tomcat 6 “coincidentally” orders it, but Tomcat 8 does not. Summarized, the loading order is as follows: bootstrap/system … Read more
I always heard that Classloader unloading was problematic. They are theoretically garbage collected when there is not reference to the object instances and class unloading is not necessary, but in practice it seems like to be more problematic. Subtle references may leak and prevent the Classloader from being reclaimed. In application servers, after numerous redeploy … Read more
Class.forName() will always use the ClassLoader of the caller, whereas ClassLoader.loadClass() can specify a different ClassLoader. I believe that Class.forName initializes the loaded class as well, whereas the ClassLoader.loadClass() approach doesn’t do that right away (it’s not initialized until it’s used for the first time). Just found this article when looking to confirm my summary … Read more
(Thanks to Aleksi) This code: public class TestLoaded { public static void main(String[] args) throws Exception { java.lang.reflect.Method m = ClassLoader.class.getDeclaredMethod(“findLoadedClass”, new Class[] { String.class }); m.setAccessible(true); ClassLoader cl = ClassLoader.getSystemClassLoader(); Object test1 = m.invoke(cl, “TestLoaded$ClassToTest”); System.out.println(test1 != null); ClassToTest.reportLoaded(); Object test2 = m.invoke(cl, “TestLoaded$ClassToTest”); System.out.println(test2 != null); } static class ClassToTest { static { … Read more
You’re going the right way. You must take some things into account. The normal thing is classes that exist in parent classloaders are used. So if you want two versions those classes must not be there. But if you want to interact you can use reflection, or even better a common interface. So I’ll do … Read more
Citing the API doc: Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader.
I think this is an XY problem. Accessing the URLs of all resources on the classpath is not a supported operation in Java and is not a good thing to try to do. As you have already seen in this question, you will be fighting against the framework all the way if you try to … Read more
Try this. It’s a hackerish solution but it will do. The field classes in any classloader (under Sun’s impl since 1.0) holds hard reference to the classes defined by the loader so they won’t be GC’d. You can take a benefit from via reflection. Field f = ClassLoader.class.getDeclaredField(“classes”); f.setAccessible(true); ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); Vector<Class> classes … Read more
Have you tried to use the JVM option -verbose:class. It displays all loaded JAR files and classes. Example: [Opened C:\Program Files\JDK160~1\jre\lib\rt.jar] [Loaded java.lang.Object from C:\Program Files\JDK160~1\jre\lib\rt.jar]
If the classloader uses URLs, it must be a URLClassloader. What you have access to is the URLs which defines the classpath for it along side with its parent ClassLoader. To get the URLs, simply do the following: ((URLClassLoader) (Thread.currentThread().getContextClassLoader())).getURLs()