Just pulling a reference book from my shelf with the javadoc: "The default
implementation of this method does nothing;" - as you indicated. "Subclasses
of ClassLoader should override this method..."
1. "should" versus "shall" or "must". Acknowledge the issue, but maintain I
have a right to consider this expected behavior.
2. Use of "loadClass". I put a lot of thought into making this performant...
potentially there can be multiple hits on a resource, and I don't want to load
all the classes. Consider the situation where discovery locates multiple XML
parsers... do you really want it to load all of them? No. You want your
application to determine which one it wants... or you want the discovery
helper classes to load the first one only.
3. Discovery does more than load classes, it locates any resource available
from the classloader. Do to this (nested jars within jars?) it works on and
is capable of returning lists of resource names (URLs) which can be
individually loaded. Again, for performance reasons we don't want to force
loading of these resources - we want to discover & report.. and let the
applicaiton drive loading.
AGAIN Bottom line, a ClassLoader that does not support discovery of
resources is, by my definition/understanding of the goals/purposes of
discovery, not usable by discovery. Some elements of discovery may be able
to be made to work [as you have shown] with impacts on performance.. but are
not generally useful.
In this case, with your patch, discovery may locate your class, but would be
unable to locate other resources within that nested jar file (property files,
META-INF/services/*, whatever)... a further patch would be necessessary
[getResourceAsStream] which only compounds the resource problem I raise.
So, we have a conflict here I suppose we need to resolve. Anyone else care to
comment on the performance issue of using loadClass [runtime AND memory] and
getResourceAsStream versus a more "adaptable" discovery mechanism that works
with err.. 'partial' ClassLoader implementations?
Is there a URL/URI pattern that covers nested jar files that would be
meaningful and useful for such a classloader?