Hallo Ben,
* Ben Burton wrote:
>I'm really not sure what you mean here. At the moment, using $CLASSPATH
>is somewhat *more* portable across different JVMs than using -classpath.
>In particular, it doesn't suffer from the ever-changing command-line
>syntax, nor does it override the bootstrap classpath.
Ok, I don't actually mind. The only real argument I have is that it
looks better, if you have all requirements defined with comandline
arguments, not environment variables. But ok... neither gij-3.0 nor
gij-wrapper-3.0 have a -classpath option... What a --ing mess.
>Then why push for $JAVA_HOME, which suffers from the same problem?
Because I think there are a lot of programs, which rely on the
'java.home' property to be set. Here is for example the result on
going thru the ant tasks. ant is IMO one of the important packages,
which should be made working out of the box.
BTW: I think that ant in main will not work, when there is a javadoc
task specified in the build.xml. Don't know if that counts as a RC
bug...
* Javac isn't a problem, as it uses Class.forName() for almost
everything or simple assumes, that the binary is in the path. Can be
made working with alternatives, by specifying a classpath wihich
include the build.compiler.
* Almost all other tasks (cvs, zipper, etc) rely on the fact that the
binary is in the path.
* Javah relies on a special sun.com...javah.Main class. Doesn't matter..
* some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home
or java.home/../ -> big problem, if that binary doesn't exist
* javadoc relys on the fact that there is a 'bin/javadoc' in java.home
or in java.home/../. -> big problem, if that binary doesn't exist.
For the last two problems see the JavaEnvUtils class.
The problem is, that we can't really patch ant to use /usr/bin/ as a
it also uses some specific tests (mainly, whether some classes are
available in the Classpath) to determine, which version javadoc is and
set special options wich only works with that version.
I have no idea, how we will work around this. There are several
options, which come to mind:
* Patch all VMs, so that java.home points to the right dir, which
includes this commands in the right version (symlinks, Depends:).
* add a facade around every javadoc and java and submit a *big* patch
to ant. Same idea as javac task. Cleanes sollution, but probably not
manageable by debian-java.
* patch ant, to include /usr/bin in the search path for any command.
Would also mean, that we have to patch ant so that it always results
in a special interface (-> java Version) and make wrappers for the
commands, so that they don't fail if that interface is used.
* patch ant, so that the algo for choosing a javadoc (and bin/java) is:
return, as a last option, the debian javadoc in /usr/bin. Example:
if (version == 1.4){
return "/usr/bin/javadoc-1.4";
else if (...) {...}
The first or the last are probably the easies and best sollutions. The
last might result in 'javadoc not found' even of there is a javadoc,
but this javadoc can't understand the specific version. This can be
worked around with wrappers, which translate ptions or simple ingnore
unknown options.
Same procedure for jarsigner, java.
As I think that we can assume, that javah and jarsigner aren't that
important to debian build process, I think it is best to get with the
first or last option. For the first, we simple have to make
development versions of each JVM package and let it include a complete
java.home dir, so that ant will work (has ant a test suite?).
For the last option:
* submit the patch for ant
* add virtual packages and alternatives for 'javadoc-version' and
'java-version'. In this case, the only requirement for javadoc would
be that it can take all options of that specific version, without
failing. So a wrapper, which translates the options would be enough.
'java-version' would still be reserved for unfree VMs, but free ones
would need to add a 'bin/java' next to the bin/kaffe in their
java.home.
Oups, also not possible (all of this properties are used by ant...)
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
[EMAIL PROTECTED]:~/tmp$ java Main
java.vm.name: Java HotSpot(TM) Client VM
java.version: 1.4.1
java.home: /usr/lib/j2se/1.4/jre
java.vendor: Blackdown Java-Linux Team
java.vm.vendor: Blackdown Java-Linux Team
os.name: Linux
java.exec.dirs: /usr/lib/j2se/1.4/jre/lib/ext:/usr/lib/j2se/ext
java.class.path: .
[EMAIL PROTECTED]:~/tmp$ kaffe Main
java.vm.name: Kaffe
java.version: 1.0.6
java.home: /usr
java.vendor: Transvirtual Technologies, Inc.
java.vm.vendor: Transvirtual Technologies, Inc.
os.name: Linux
java.exec.dirs: null
java.class.path:
.:/usr/share/kaffe/Klasses.jar:/usr/share/kaffe/comm.jar:/usr/share/kaffe/pjava.jar:/usr/share/kaffe/servlet.jar:/usr/share/kaffe/tools.jar:/usr/share/kaffe/microsoft.jar:/usr/share/kaffe/kjc.jar:/usr/share/kaffe/rmi.jar
[EMAIL PROTECTED]:~/tmp$ gij-wrapper-3.0 Main
java.vm.name: libgcj
java.version: 0.0.7
java.home: null
java.vendor: Free Software Foundation
java.vm.vendor: Free Software Foundation
os.name: Linux
java.exec.dirs: null
java.class.path: .
--8<---------:- snip -:---------8<---------:- snip -:---------8<--
Can anyone test, what kaffe 1.1.1 sets as java.home?
class Main{ public static void main(String[] args){
System.out.println("java.home: "+ System.getProperty("java.home"));
}}
But in this case the patch would be fairly easy:
/usr/bin/kaffe:
| KAFFEHOME="${exec_prefix}/lib/kaffe"
Have I already told you, that I didn't expect that this is getting so
--ing complicated...?
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
