When using jh_depends in the "arduino" package (and soon to be
packaged "processing-java" package), jh_depends correctly identifies
tools.jar and rt.jar to be from openjdk-6-jdk. However, those jars are
also available in sun-java6-jdk.

Users asked that the package depend on: openjdk-6-jdk | sun-java6-jdk.

Would it be possible to have a "quirk" where if jh_depends finds jars
from openjdk-6-jdk it replaces java:Depends with "openjdk-6-jdk |
sun-java6-jdk"?

Right now I'm not using the substitution variable and listing the
packages individually so I can have "Depends: openjdk-6-jdk |
sun-java6-jdk"

Hi

I do not understand that these jars are mentioned in the classpath in
the first place. The JVM should load these itself, so you should not
have to mention them.

The preferred way of choosing a JVM is by using the --jvm argument[1].

~Niels

[1] Just a heads up, the semantics of --jvm will change slightly in 0.32
in regards to how "headless" is interpreted.

Thanks for the reply

"Processing" is a java package which compiles java code, so it depends
on the jdk. The package won't build unless tools.jar is explicitly in
the classpath at build time (I'm not too familiar with that package, i
work with arduino so I don't know what happens if tools.jar isn't in
the classpath at runtime for processing).

"Arduino" is a derivative of Processing which compiles C code, but is
based on the Processing classes, and won't build unless tools.jar is
explicitly in the classpath (spits out undefined class errors).
tools.jar is apparently used when compiling code, that's why it's in
the jdk and not in the jre [1,2]. However, "java-propose-classpath" on
arduino.jar only sees symbols of three .jars: the arduino.jar itself,
and two java library packages (not the jdk).

Maybe we can use javahelper to define one classpath during build time
and another for runtime? (I've tried but haven't found how to do it
yet using jh_build and setting CLASSPATH and/or using .classpath, and
I haven't tested if the package would even work - just a theory) I
have a feeling that having a different classpath than the build time
classpath isn't that good of an idea, especially when upstream's
wrapper for launching the .jar [3] does the following:

for LIB in \
    java/lib/rt.jar \
    java/lib/tools.jar \
    lib/*.jar \
    ;
do
    CLASSPATH="${CLASSPATH}:${APPDIR}/${LIB}"
done
export CLASSPATH


We don't do that in debian, since CLASSPATH is defined before jh_build.


This might be a really unique case, but I guess the quirk would be if
tools.jar is found in the classpath to include either the openjdk OR
sun jdk since the file exists in both and only one is installed during
build time (the one in main). I'd understand if it's too much to
change and maintain the change for the few java packages that would
depend on tools.jar, I'll defer to your experience and opinion.


[1] http://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=tools.jar
[2] http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/tooldocs/solaris/jdkfiles.html
[3] http://arduino.googlecode.com/svn/trunk/build/linux/dist/arduino

tag 588379 wontfix
thanks

Hi Scott, I'm the other Javahelper maintainer,
"tools.jar" - how is this loaded by the JVM? I would expect it wouldn't know
where to look. If you explicitly list the path to tools.jar, then it'll only
load the one from that JVM - and hence you should depend on just that.

I expect what you actually want to do is either list both in the manifest or
select it at runtime and hence don't need it in the manifest (and, I see below,
this latter is what you do).

My view is that this really is a corner case and the automated tools
like jh_depends are designed for the common case, so the easiest solution
may be to just list the depends yourself.

Well, your wrapper here is setting the classpath, so you don't need it to be in
the jar. The other option would be to use jh_build to build (doesn't upstream
have a build system?) and then jh_classpath to remove the classpath, then you
can put the depends in manually and have the wrapper script (as it does) set
the classpath at runtime.

Yeah, I think that's probably the case here, but thanks for asking about it -
it's certainly an interesting case!

Matt