David Holmes wrote: > Jeroen Frijters wrote: > > > > * java/lang/Class.java > > (forName(String,boolean,ClassLoader)): call > > ClassLoader.loadClass(String) instead of > > ClassLoader.loadClass(String, > > boolean). There are ClassLoader subclasses out there that override > > loadClass(String) instead of loadClass(String, boolean). > > I agree a change is needed but a different change. The current 0.05 > code confuses initialization with resolving/linking. Class.forName > must link/resolve the class before it can return the Class object - > but it need not initialize the class depending on the initialize > parameter. The existing code passes the initialize parameter as the > resolve parameter to ClassLoader.loadClass and that is wrong. The > Class.forName method must invoke loadClass(x, true) to ensure the > class is resolved.
The current code doesn't confuse resolve/initialize, I just didn't know that Class.forName was required to resolve the class. The reason it passed the initialize parameter as the resolve parameter was that initialization requires the class to be resolved (although it needn't be done explicitly, initialization should also trigger a resolve). Calling ClassLoader.loadClass(String, boolean) from Class.forName is incorrect and, more importantly, incompatible with Sun's implementation, so I think an explicit call to ClassLoader.resolveClass has to be inserted. Agreed? Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
