Marshall Schor created UIMA-5038:
------------------------------------
Summary: 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 is probably the
best choice, as it may enable correct operation in the presence of applications
using OSGi or Thread Local Class Loader conventions, so I'm inclined to leave
it (but this Jira will still do the refactoring).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
