Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> Packages, which want to contribute a alternative for /usr/bin/java and its
> >> manpage must provide java-runtime. The alternative must accept the option
> >> '-classpath', which sets the classpath and autmatically adds the right
> >> rt.jar. The must depend on java-common.
> >You need to specify what you mean by setting the classpath more closely.
> >Preferably, explain the semantics you want using an example. Current wording
> is
> >too vague.
>
> It seems that the interface specification will get really long (see
> the other post asking for more options to be included in that list)
> -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? ;) What's wrong with relative paths? 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 ...
A lot of these are questions that you get to ask yourself when you write system
class loaders in a VM. I'm trying to get you to realize that Sun has changed
their CLASSPATH spec a couple of times in incompatible ways and that you can't
cater for them all, so you have to pick an interpretation and stick to it.
Different VM writers will pick different interpretations.
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.
I'm trying to show you that some parts of your java policy are quite good,
while others are too vague. When I try to pin down the vague parts, we get into
the morass of different specs by Sun. To me, this means you should drop the
vague bits if they can't be specified exactly ;)
> >> Priorities should be set as follows: highest Spec version multiplied with
> >> 100 (1.4 -> 140), free VM may add 30 points, for incomplete spec
> >> compatibility subtract 30. Revisions may add 1 point, as appropiate.
> >Uh, is this really necessary? It seems like a quite awkward spec compliance
> >rating system.
>
> IMO yes. This will ensure, that when using java, the best and
> latest version of instaleld JVMs will be /usr/bin/java. This will be
> the best and wanted case in most cases.
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. ;)
> >> * 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
5.3.1.2 What are the problems with Suns' new license?
Sun has moved to a new license the Sun Community License, like the GPL it is a
viral license, but making all it touches subject to Sun licensing fee. The SCSL
even goes so far as to define any implementation of a Sun specification as a
"Modified Work". Basically, this means that if you implement any part of the
new 1.2 API or Jini API, even from scratch, Sun will "own" your implementation
and you will have to pay them for the right to use it.
13. "Modification(s)" means (i) any change to Covered Code;
(ii) any new file or other representation of computer
program statements that contains any portion of Covered
Code; and/or (iii) any new Source Code implementing any
portion of the Specifications.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: