On 9/6/05, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Thomas Dudziak wrote on Tuesday, September 06, 2005 9:09 AM: > > [snip] > > > > * 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 > > Just out of curiosity: Why? These classes will always come from the system > classloader
Are you sure they will ? What would hinder a custom classloader to load them on its own ? > > * int.class is not guaranteed to be equal to Integer.class > > Any reference? I am quite sure, that this will break a lot of apps (at least > those who rely on DataInput/DataOutput). And you would no longer be able to > serialize between different runtimes ... int.class != Integer.class (or Integer.TYPE != Integer.class) because Integer is a different class. AFAIK Java's reflection does some magic (some sort of assignment conversion) to match methods/fields with a primitive type against their wrapper type. For instance: http://www.jguru.com/faq/view.jsp?EID=20857 If you try in a use case assertEquals(int.class, Integer.class); this will always fail whereas assertEquals(int.class, Integer.TYPE); will succeed. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
