[ https://issues.apache.org/jira/browse/UIMA-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668628#comment-15668628 ]
Marshall Schor commented on UIMA-5038: -------------------------------------- Some refactoring was done to use common code for loading. I didn't change it to use loadClass - it still uses Class.forName, because of reading there's perhaps some other mysterious edge cases if you don't use the forName style. If a OSGi user complains, we may revisit. > UV3 refactor class loading for consistency / maintainability > ------------------------------------------------------------ > > Key: UIMA-5038 > URL: https://issues.apache.org/jira/browse/UIMA-5038 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework > Reporter: Marshall Schor > Priority: Trivial > Fix For: 3.0.0SDKexp > > > There are 4 main places the UIMA framework loads classes: the Framework > itself at startup, Resources, Annotators (a kind of resource) and JCas > Classes. The last 3 can make use of UIMA extension class loaders, or PEAR > isolation class loaders. > Refactor the code to have these where possible use common code. > One issue to confirm: the current code uses 2 methods for loading classes: > Class.forName and classloader.loadClass. The Class.forName has a variant > which takes 3 arguments, making it functionally equivalent to the loadClass. > But its operation is subtly different in that it caches the reference to the > loaded class, *even if it isn't the defining class loader*, whereas loadClass > doesn't do this. See > http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html > for a discussion of this, and the comments for a reply from Oracle tech > support saying: > bq. Applications should basically never call Classloader.loadClass(). It may > appear to work but it is often subtly wrong, can be a source of latent bugs, > and is almost never the best choice. They should instead call Class.forName() > using the 3 parameter version that takes a specific Classloader instance. > Our current code always (I think) uses Class.forName for the case where there > is no UIMA class loader, and loadClass otherwise. I think this would cause > failures in an OSGi loading scenario, where one of the parent loaders was an > OSGi loader and it dynamically switched its "parent". The expectation would > be that the child loader (the UIMA class loader), the next time it was called > to load something *not* in its set of classes, would delegate to the parent > chain and the OSGi loader would now load from whatever was it's current > "parent". But instead, because the UIMA loader would have "cached" the > class, it would instead be stuck getting the old class forever (unless the > old class was eventually GC'd) > Therefore, I think to work properly in this scenario, we must always use > loadClass, and never Class.forName. > The one known issue of loading named arrays doesn't arise in our case, unless > from some highly usual user code, and we can catch this and use Class.forName > in this instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)