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:13:29 GMT
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.

2.  See above.

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.

-----Original Message-----
From: Thomas Dudziak [] 
Sent: Tuesday, September 06, 2005 8:59 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] enhanced version of Class.forName

On 9/6/05, James Carman <> wrote:

> 1.  In an environment where a SecurityManager is installed (if you're
> running code that is going to try to replace system classes, I'd suggest
> it), code has to be given the permission to instantiate a ClassLoader.
> Also, that ClassLoader has to be given the rights to define classes in
> certain packages.  So, it's highly unlikely that Integer.TYPE will be
> different in different threads within the same VM.

Yep, but not impossible. And this dependency is not necessary anyway
(see the impl that I attached to the issue; it only needs the string
map), so please, do not use Integer.TYPE or int.class directly.
> 2.  I did not assert that int.class = Integer.class.  I asserted that
> Integer.TYPE = int.class.  I have changed my code to use int.class,
> as it's shorter and more obvious as to what we're doing.

see above

> 3.  Was unaware of the problems with Class.forName().  Is everyone in
> agreement that we should use
> Thread.currentThread().getContextClassLoader().loadClass() rather than
> Class.forName()?

In a normal app these are the same, and in a scenario with multiple
class loaders (eg. a web app), the context class loader is safer IMO.


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

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

View raw message