Andrew Haley wrote: > All of this is fairly ill-specified. As usual :-( I just re-read the relevant part of the 1.5 API spec and JLS (which it refers to) and I think you can actually interpret it to prohibit loading array classes via ClassLoader.loadClass (indirectly based on the definition of "binary name").
> ClassLoader.loadClass() can to > cope with "[I", for example, and there is extant application code that > requires it. That's how I discovered the same incompatibility that > you've found. This may be a bug, or perhaps just a side-effect of a > particular implementation. It's probably a side effect from the fact that findLoadedClass looks in the hashtable that contains all classes associated with a class loader. Once the array classes get created they're presumably stuffed into the hashtable (it's what I do at least) and subsequently they show up in the ClassLoader.loadClass() path. > Is there a strong reason to prefer fixing all the clients of > loadClass() ? There doesn't seem to be any strong specification > reason to do so. I don't have any strong arguments for doing that, but it feels like it's the right thing to do to me. Regards, Jeroen _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
