Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
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 jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: