[armedbear-devel] ABCL packaging ASDF system in jars (was Re: Disabling "built-in" output translation)

[Mark Evenson]

On 5/17/11 10:24 PM, Alessio Stalla wrote:
[…]
> a. CLASSPATH (the listing of directories and jar files where to look
> for classes) is not a runtime concept; it's only a variable
> (environment variable or command line switch) used to init the JVM's
> default class loader. Once the JVM is started, CLASSPATH doesn't make
> any more sense.
> b. At runtime there's a hierarchy of class loaders, that, without
> going too much in detail, define a sort of limited virtual filesystem.
> Resources in that filesystem might come from plain files, from
> contents of jars, from the network, from memory... So,
> classpath:foo.jar!/bar does not make much sense: the fact that bar
> comes from foo.jar is no longer important (and possibly not even known
> anymore) inside the virtual filesystem. This is not just theory, I can
> cite at least two examples: ABCL's very own functions compiled at
> runtime and loaded from memory, and anything running on JBoss>= 5,
> where applications are loaded with a classloader that does not expose
> jar files in any way. So, I would suggest simply
> classpath:/foo/bar/baz and leave it to the classloader to go and find
> /foo/bar/baz. This is precisely how the Spring framework does it, for
> example[1]. What you lose is the ability to enumerate the contents of
> the "file system": you can only ask for a resource by name and get
> back a stream if it exists. But I don't think we currently need the
> capability to enumerate.

So, if I understand you, 'classpath:/foo/bar/baz' just means find the 
entry '/foo/bar/baz' relative to something within the classpath?  What 
happens if there are multiple classpath entries that satisfy this 
requirement, i.e. foobar.jar and barfoo.jar both contain '/foo/bar/baz'? 
   Doesn't a "first one wins" strategy create ambiguity?

[…]
-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."