[armedbear-devel] JAR file support patches

[Alan Ruttenberg]

On Tue, Jan 26, 2010 at 2:17 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Tue, Jan 26, 2010 at 1:21 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
>>>> Incidentally, we may be able to autodiscover .asd files by scanning
>>>> the classpath, and suitably update asdf:*central-registry*.
>>>
>>> We first need to agree on a convention to wedge the concept of Pathname
>>> into CLASSPATH.  I now support your earlier proposal to keep the two
>>> separate, as it makes more sense.  And I'd like to get the "jar:" part
>>> of my changes into the trunk, and tested for a bit before introducing
>>> another the next step.  Right now, wildcards (and DIRECTORY) don't work
>>> inside JARs which would be the first step to autodiscovery.
>>
>>
>> With Java resources, one is always warned against using the classpath that way. Looking for a particular path is possible, but listing paths (or files) not. It might be safer to introduce an additional concept. This could be an explicit list of Java resource paths or a new kind of ASDF classpath.
>
> Scanning the entire "classpath" (or better, the resources known to
> classloaders) in general is impossible, since a classloader can create
> a resource from anywhere (e.g. from a buffer in memory, like ABCL
> itself does for runtime compilation).
>
> However, it is possible to scan the classpath in the most common
> cases, i.e. when the resources are either on the filesystem or in some
> Jar loaded by a regular URLClassLoader.
>
> I agree that doing it right, for some value of right, is far from easy
> as there are tricky cases (e.g. classloaders used by some application
> servers) that you might still want to handle.

FWIW, DWIMming the classpath doesn't seem worth the effort. If we can
do directory inside and outside jars and get access to the classpath
then people can easily build things on top of that.

-Alan