CDV ❯ class export feature does not work in all cases
-
Bug
-
Status: Open
-
2 Major
-
Resolution:
-
Byte Code Transform
-
-
interfaces
-
Reporter: teck
-
January 28, 2008
-
0
-
Watchers: 0
-
December 16, 2011
-
Description
The DSO client (and the TIMs it contains) can “export” classes to application level classloaders. The implementation is essentially a VM wide map that provides URL sources for specific classnames. Inside of the base java.lang.ClassLoader class, we add a hook which consults this map whenever classes are being loaded. If there is an entry present in our map, then we use the URL source to get the bytes and define the class in the initiating loader.
Our hook is present in ClassLoader.loadClassInternal() however (the VMs entry point for implicit class loading). For explicit loading via loadClass(..), the hook for export is not invoked.
This isn’t simpy a matter of just moving the hook though. loadClassInternal() has the nice feature that it only called once per class to load (this is not true of loadClass). The other thing about loadClass() is that it can (as frequently is overridden in loader subclasses).
The workaround for code that wants to explicit class loads *and* needs to see “exported” classes is to use Class.forName(String, boolean, ClassLoader) instead of loadClass(..)
To be even more specific about this. The issue will only happen when a custom classloader doesn’t use getResource(name) to find the class it will load. I’m also wondering, shouldn’t a classloader delegate to its parent and the system classloader first? We could maybe tie into the findSystemClass method call to have exported classes being considered part of the system classpath?