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.
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. 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()? -----Original Message----- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 06, 2005 3:09 AM To: Jakarta Commons Developers List Subject: Re: [lang] enhanced version of Class.forName On 9/6/05, James Carman <[EMAIL PROTECTED]> wrote: > I would say that this is something that would be very useful. We did > something similar in HiveMind. I can imagine an implementation like: > > private static Map typeMap = new HashMap(); > private static Map abbreviationMap = new HashMap(); > > static > { > typeMap.put( "int", Integer.TYPE ); > typeMap.put( "boolean", Boolean.TYPE ); > typeMap.put( "float", Float.TYPE ); > typeMap.put( "long", Long.TYPE ); > typeMap.put( "short", Short.TYPE ); > typeMap.put( "byte", Byte.TYPE ); > typeMap.put( "double", Double.TYPE ); > typeMap.put( "char", Character.TYPE ); > > abbreviationMap.put( "int", "I" ); > abbreviationMap.put( "boolean", "Z" ); > abbreviationMap.put( "float", "F" ); > abbreviationMap.put( "long", "J" ); > abbreviationMap.put( "short", "S" ); > abbreviationMap.put( "byte", "B" ); > abbreviationMap.put( "double", "D" ); > abbreviationMap.put( "char", "C" ); > } <snip> This is similar to my implementation with three important differences: * the direct usage of types (Integer.TYPE etc.) has obviously problems in environments with multiple class loaders (eg. Class.forName(String name, boolean initialize, ClassLoader classLoader); likewise there may or may not be issues with using static in this context * int.class is not guaranteed to be equal to Integer.class * Class.forName is known to be problematic in certain circumstances/environments; using Thread.currentThread().getContextClassLoader() might be more useful (as Henri/Stephen suggested). I'll add an issue for this in BugZilla with my code attached, and you guys can decide whether it is useful to include in commons-lang, ok ? regards, 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]
