commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: [lang] enhanced version of Class.forName
Date Tue, 06 Sep 2005 13:35:58 GMT
Well, I just tried your code against my test cases and it fails in two

1.  It doesn't throw an IllegalArgumentException when you pass in null.
2.  It doesn't hand the actual java class names for array types (i.e.

Now, it could be argued that an NPE is just as good as
IllegalArgumentException in the first case, but the second case is
definitely something that it should support.

-----Original Message-----
From: Thomas Dudziak [] 
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 <> 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
> (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.
> 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 ?


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message