commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
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 [mailto:tomdzk@gmail.com] 
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 <james@carmanconsulting.com> 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,
though,
> 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()?

+1
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.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message