One thing to watch out for here is the loadClass expects a binary name. I think forName does not, at least the Javadoc does not say so (and I cannot experiment ATM, on my phone).
Gary On Aug 25, 2012, at 14:58, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > In [lang] there are a few places where Class.forName(String, boolean, > ClassLoader) is used to load classes dynamically (e.g. in > ClassUtils.getClass()). > > According to the book "OSGi in action" (written by guys from the Felix > community) it is recommended to use ClassLoader.loadClass() instead. The > reason - IIUC - is that Class.forName() does a more aggressive caching; it is > possible that the same Class object is returned even if a different class > loader is passed in. This may cause trouble in environments like OSGi. > > So should we switch to ClassLoader.loadClass() to be on the safe side? The > only problem I see is that the API of ClassUtils.getClass() is pretty much > tailored towards Class.forName(); it expects the same arguments. Especially > the boolean initialize flag is not supported by ClassLoader.loadClass(). I am > not sure whether this is really an issue, but there would be a slight change > is the semantics of the getClass() method because initialization of the class > could not be triggered directly any more. > > WDYT? > Oliver > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
