I think that we would have to ask for classloader advice ;-)
I suspect we would need:
loadClassSystemClassLoader() - Class.forName loadClassThreadContextClassLoader() - thread loadClassLangClassLoader() - from ClassUtils loadClass(ClassLoader)
;-)
Stephen
----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]>
The important part for me is the munging that stops primitives being special and [] not working. I'm happy to replace the forName part with a better way and rename to getClass.
Would Thread.currentThread().getContextClassLoader().loadClass(String) be acceptable instead of the forName call?
Hen
On Thu, 27 Jan 2005 23:43:58 -0000, Stephen Colebourne <[EMAIL PROTECTED]> wrote:While I support the addition of a get class method in principle, I am
concerned that this brushes over the class loader issue. I would say that
Class.forName() will often cause problems, so maybe this isn't the best way
to code this.
Stephen
----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> >I committed this btw. > > Hen > > On Wed, 26 Jan 2005 17:34:39 -0500, Henri Yandell <[EMAIL PROTECTED]> > wrote: >> I'd like to add ClassUtils.forName; to all intents and purposes the >> same as Class.forName except that: >> >> 1) It understands arrays ending with [] instead of the [L<class>; >> ugliness. >> 2) It can handle primitives, "int" would correctly return int.class. >> 3) (perhaps?) null-safe. No idea really, just throwing it in :) >> >> Hen >> > > --------------------------------------------------------------------- > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
