Re: store reference detection (was Re: JARs and reference scanning)

[Ricardo Wurmus]

Chris Marusich <address@hidden> writes:

> Ricardo Wurmus <address@hidden> writes:
>
>> Chris Marusich <address@hidden> writes:
>>
>>>> Jar files can be told to import classes from another Jar by adding it to
>>>> the “Class-Path” field of the Jar’s manifest.
>>>>
>>>> Here’s an example:
>>>> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html
>>>
>>> I didn't know this!  That's awesome; it might be just what we need.
>> […]
>>
>> Thanks for testing this!
>>
>> One limitation appears to be that this only works for applications, not
>> for libraries.
>
> In what way does this not work for libraries?  I'm not criticizing you;
> I'm genuinely curious.  To ask this question another way: how would a
> solution that "works for libraries" behave, exactly?  I'm not sure what
> the phrase "it works for libraries" might mean, since I suspect its
> meaning varies depending on what one is trying to accomplish.

What I mean is that it may not be transitive.  Let’s say “java-foo”
depends on “java-hamcrest-core”, so we record the absolute path to the
hamcrest core jar in the Class-Path field of the manifest.

Now let’s also say that the application “java-bar” depends on
“java-foo”, but not directly on “java-hamcrest-core”.  Now what I wonder
about is whether we would need to record the paths to the jars of both
“java-foo” *and* “java-hamcrest-core” in the Class-Path field of the
manifest for “java-bar”, or if it would be sufficient to record
“java-foo".

Would Java respect the Class-Path for all dependencies recursively
within their scope?  Is this ‘lexically scoped’ (i.e. the specified
class path will apply only for the jar on whose manifest it was
specified) or will Java traverse all Class-Path fields and create one
concatenated big class path that is used to resolve all classes?

In the latter case there could be conflicts when one node in the graph
demands *one* version of a jar and some other node demands the classes
from a *different* jar to be used.

Maybe none of this is implemented and all Class-Path does is tell the
current *application* where to get its dependencies; in that case the
Class-Path field would just be an alternative to using a shell wrapper
that sets the CLASSPATH environment variable.

Does this make it a little clearer?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net