uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Created] (UIMA-5038) UV3 refactor class loading for consistency / maintainability
Date Wed, 03 Aug 2016 14:11:20 GMT
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)

Mime
View raw message