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?
[…]