On 9/6/05, James Carman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
