Hallo Dalibor, * Dalibor Topic wrote: >> -classpath <jarfile>:<jarfile>, where <jarfile> is a full path to a >> Java Archiv file. >So you've just forbid the use of directories in -classpath per policy. >Are you sure you want to do that? ;)
In packages: yes. Policy requires, that all puiblic jar files are in /usr/share/java. You can have conflicting jars in there (for example libswt2.1-*-java has two times the swt APi in there). This will result in errors I don't want to debug. Together with the 'Jar Descript Files' idea, this will be as easily handled, as setting a complete dir on the classpath. >What's wrong with relative paths? Oups, yes, thats true. 'path to a jar file'. >And finally, what's the effect of -classpath a.jar:b.jar supposed to >be? How does it alter the class lookup? What about the current >directory? Is that included automatically? And so on ... If we want to have policy define things that deep down, we will never get anything done. This interface for /usr/bin/java and /usr/bin/javac is not to be used in packaging. This 'interface' is simple something to give to the user, so that not everything is different from what he knows. >A lot of these are questions that you get to ask yourself when you >write system class loaders in a VM. But I'm not. I try to write a policy for debian. >Codifying a particular behaviour in the spec doesn't really help, >unless you want to put pressure on the maintainers to *reimplement* >Sun's class loading in java 1.1 to match the debian java spec's idea >of class loading taken from java 1.4. What i want is, that 'java -classpath ./this.jar HelloWorld' will work. For packages, /usr/bin/java shouldn't be used, but /usr/bin/java-1.4 (protected by the fact that only ~100% compatible JVM will provide it), /usr/bin/kaffe-1.1 and so on. I will clearify this points and post a new version (day after) tomorrow... >Then you need some authority to determine the 'best and latest version' of >free VMs for those people who don't want to install non-free software (a lot of >debain users, I think). I propose the creation of a >debian-who-s-got-the-best-free-java mailing list for bug reports about VM >compatibility ratings, flame wars about whose CLASSPATH is longer, and of >course the never-ending religious wars between kaffe and gcj zealots. No, >please don't do that. ;) Just setting them all to 200 isn't any better. This priority system should IMO fullfill this goals: * get a newer version before the older one * get a more spec complient version before any not so spec complient version. * get a free one before a unfree one. IMO in this order, as the first two 'make it work'. But other opinions my differ. Please give me a different way. The alternative can be overwritten easily, so if you are of a different opinion, just do it. >> >> * Sun's Community Source Licence. Can we use it? How? The 2.3 >> >> version of the text can be found [19]here. >> >I doubt it, since it's not free software in the DFSG sense. It was not even >> >open source last time I looked at it;) >> So this part should be removed, if thats clear. >According to the debain Java FAQ: >http://www.debian.org/doc/manuals/debian-java-faq/ch5.html So it should have been remove already... Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm."
