Okay, I caved (or compromised)! :-) I re-wrote the method to use your little trick of loading the array version of the class and taking the component type. The only problem I have with this is that I'm passing the "initialize" parameter in when I call forName() for the array version. I guess it doesn't really hurt to initialize the array version, but does that cause the component class to get initialized? Of course, this only happens for primitives, so it's probably not a big issue, since the primitive classes will most likely be loaded by the bootstrap classloader. I'm attaching the code as a patch for others to review.
I still have the problem that my code uses a regex to check the validity of the class name that's passed in. Darn backward compatibility! -----Original Message----- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 06, 2005 9:24 AM To: Jakarta Commons Developers List Subject: Re: [lang] enhanced version of Class.forName On 9/6/05, James Carman <[EMAIL PROTECTED]> wrote: > 1. If you're going to use that logic, then who is to say that the > String.equals() or String.hashCode() method is implemented correctly? > You're using a HashMap (so am I) that has Strings as keys. In your scenario > (EvilClassLoader), the String class could be replaced with another class > that totally messes things up. I think this point is a non issue and not > worth coding around. Very unlikely to occur and if it does, then shame on > whoever wrote the code. Erm, I think that is a non-argument. I was not talking about evil classloaders, only about class loaders that also handle core classes - nothing evil about that. My argument was that it is not necessary to perform such special logic that hardcodes against the *.TYPE constants (loaded by the system class loader). In fact not doing this is slightly easier as the same mechanism is used for every class (no coding around primitive classes), and only one hashmap is used instead of two. Don't get me wrong, I do not want to push my implementation or something. However IMHO the usage of *.TYPE is not only not necessary (it does not bring any benefits) but also somewhat dangerous in regard to custom class loaders. And "very unlikely" are these things that make hard-to-find errors that drive us nuts when debugging. > 3. I changed my code to use the classloader's loadClass() method, also. My > vote would be +1 to using the classloader if it really is safer. I wonder whether the long version Class.forName(String name, boolean initialize, ClassLoader loader) or ClassLoader.loadClass would be better ? Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
