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. > > 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()?
To work correctly in a J2EE environment, you need to check the context class loader first, use it if it is non-null, and use the implementing class's class loader if it is not. You can't assume that there will always be a context class loader. -- Martin Cooper -----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] > >
