Jeroen Frijters wrote: > David Holmes wrote: > > Why is it incorrect to call loadClass(name, true)? > > Because it isn't public. The fact that it happens to be accessible > because it is protected and Class happens to be in the same > package as > ClassLoader doesn't mean it is right to call it. Plus, the fact that > loadClass(name) is public and non-final means that subclasses can > override it, so we need to call that to be compatible.
I find that logic rather strange. It could be that the main intent was to allow loadClass(String, boolean) to be package accessible and that it was made "protected" because it might be useful for subclasses to override. In short there is nothing wrong with classes within the same package using package accessible methods. ;-) > True, but you do know that in most VMs "linking" is a no-op, right? I was simply showing how the semantics of the methods matched. You certainly can't assume that linking/resolving will actually be a no-op. > This is *not* in internal implementation detail. I've > written a custom > class loader and ran it under the Sun VM and observed the > Classloader.loadClass(name) being called from Class.forName(). ?? ;-) Did you also observe ClassLoader.resolve() being called? Given that loadClass(name) is specified as equivalent to loadClass(name,false) I see these as functionally equivalent: Class clazz = cl.loadClass(name); cl.resolveClass(clazz); vs. cl.loadClass(name, true); You can prefer the former if you like, but the latter is certainly not incorrect. Mind you, the former requires that you invoke the non-public resolveClass() method - so by your earlier reasoning that would be incorrect. In which case I'm not sure how you will resolve/link the class as required by Class.forName. ;-) > This isn't some random thing I dreamed up. I actually ran into this > problem while trying to get JBoss to run on IKVM. JBoss has a broken > custom class loader that overrides loadClass(name). Ah I see. I had no idea where this approach came from, but if JBoss is broken report it as a bug. The semantics of loadClass(name) are well-defined. Pity they didn't make it final. > I assume you mean using JNI to call ClassLoader.loadClass(name) > non-virtually. As can be deduced from the above, Sun's > doesn't do this, so neither should we. No I meant that both Class and ClassLoader could defer to a VM specific mechanism. But thinking further it's probably not an unreasonable assumption that forName actually invokes method(s) on the classloader that is passed to it. It's a pity that this isn't clearly specified though. Regards, David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
