Re: Limitations for dh_javadeps
In message: <[🔎] 20020522203401.GA27921@chrystal.opal.dhs.org>
Ola Lundqvist <opal@debian.org> writes:
>
>A perfect (?) solution would be to first search for
>things in your CLASSPATH and then /usr/share/java/*.jar, and if
>possible (or useful) search other places.
>This can give results like the following, which would be really great.
>Depends: libxalan-java | libxalan2-java
>
>It is probably not foolproof, but should be better than now. :)
The version I sent out searches CLASSPATH first, then all in
/usr/share/java/*.jar, but only tracks the first package found
which satisfies a given dependency, instead of all alternatives.
This could be improved without too much effort.
>It would be great if the tool could resolve dependencies
>on jvm:s too. At least to specify a preferred jvm. This is not
>high priority though. You probably know better what is possible
>to perform.
Unfortunately, figuring out which JVMs are appropriate is a bit
beyond the scope of this sort of tool, primarily because the
runtime libraries for the JVMs are frequently extremely opaque
to outside tools. Figuring out which version of the Java language
spec is doable just by comparing what a package uses vs. what
each spec version provides, but it'd be up to the JVM packagers
to advertize which version of the spec they support.
(For proper spec version detection, the tool should also pay
attention to which methods and fields get used on various classes
which have changed from one version to another (particularly
problematic for java.util.Vector and java.awt.*)... but it doesn't
do that yet. I'll consider that as a wishlist thing later.)
>Only to/from .jars please. Actually I think the policy states
>that only jars should be used. If not please file a bug
>against java-common.
I missed the requirement that auxiliary classes of applications
be in .jars on my first (and second) readings. Oops. I'll
munge the tool to ignore raw .class files.
>Each package should provide one
>(or several?) files that specify a CLASSPATH for the package
>(or jar?). But the specification for it have to be defiened. Suggestions
>are appriciated.
I suggest that the CLASSPATH-defining files be associated with the
.jar, not the entire package (since a single package may provide
several .jars with radiacally differing requirements). Something
in the same format as the substvars java:Depends line (except using
.jar file paths instead of package names) would likely be appropriate.
Unfortunately, having the .jars referenced directly instead of their
containing packages may cause problems if a library package doesn't
follow the naming conventions and decides to rename one of its .jars
in an upgrade.
I can easily enough make a tool which does a transitive-closure of
the runtime CLASSPATH requirements for a given set of .jars, given
the above files, whose output would be appropriate for setting a
CLASSPATH in the wrapper for an application.
I'm beginning to think that a default global CLASSPATH is not
appropriate at all, and any well-packaged program or library should
only depend on external things that are going to be found in
/usr/share/java. This does have the downside that all java programs
are going to have to be wrappered, so that they can specify JVM and
CLASSPATH...
Referencing one of the 'issues to discuss' from the proposed policy,
it should NOT be possible to fully override a JVM's core classpath.
There is a lot of magic in the core classes (java.lang.Object,
java.lang.Class, java.lang.System, and java.lang.Runtime in particular)
which is very tightly coupled to JVM implementation, and JVMs are
unlikely to function properly without their own versions of same.
Compilers are an entirely different beast, though, and it would be
nice to be able to specify the core classes you'e compiling against.
Some extant compilers do allow this.
- Alex
--
To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: