Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan.
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Ean,
>
> * Ean Schuessler wrote:
> >We must come to terms with the fact that a Debian Java policy cannot be
> >built with proprietary VMs in mind.
>
> It is already (debian java policy, chapter 2.1):
> |Packages that contain a runtime conforming to the Java 1.1
> |specification should provide java1-runtime. Packages that contain a
> |runtime conforming to the Java 2 specification should provide
> |java2-runtime. If a package conforms to both, then it should provide
> |both; however, packages that do not implement the methods from Java
> |1.1 that have been deprecated in Java 2 must not provide java1-runtime.
> |
> |They should use /etc/alternatives for the name 'java' if they are
> |command-line compatible with the Sun's java program.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Under this, kaffe couldn't add a alternative for /usr/bin/java, as the
> -classpath option didn't work as the sun one.
That's a very ambiguous definition. Sun has changed the synopsis of the java
executable between releases quite a bit.
By the way, kaffe's -classpath worked just like with Sun's java program. But
I'm talking about Sun's java executable from 1.0 or 1.1. That's an example of
confusion resulting from the whole java-alternatives mess ;)
Strictly speaking, according to debian's policy above, any free vm providing an
alternative for /usr/bin/java would imply that it is conforming to some java
spec. This can get into legal muddy waters if you consider Sun's rules for Java
compliance, which don't let you claim java compliance before you passed a
compatibility test kit (that costs a few hundred thousand euros in licensing,
AFAIK, plus NDAs for all involved). So Sun may be able to sue debian for
abusing its Java trademark by claiming some free VM is compliant with java 1.x.
That's another reason to get rid of the java alternatives mess ;)
> >There is no "make it work" when it comes to proprietary software and Debian.
>
>
> If we build a debian policy, which does not take into account, that
> there are nonfree java virtual maschines (which many people will want
> to use: browser plugin, swing java programms (bah), plain to big apps,
> which are currently not working in free alternatives), than this is
> plain stupid (sorry for the word, but that was my first thought I had
> in mind).
Well, there are non-free C compilers as well (intel, microsoft), but that
doesn't mean debian should go to great lengths to support them. I'd consider a
debian policy that says 'some people may like to use MSVC++ to build windows
applications, so all C compilers must make sure that they adhere to MSVC++'s
synopsis and behave the same' to be quite unreasonable, despite that (I assume)
a lot more people out there use MSVC++ than gcc ;)
> When I wrote my policy proposal, I didn't know how far away the free
> VM were from being '100% sun java compatible'. I will write a sligthly
> different proposal, which makes it clear, that the virtual packages are
> there to build a interface, so that ~100% sun compatible JVM can be used
> from our packages. This will leave out free VMs, which have to be
> handled independently from that (which should be ok, given the fact
> that we control, which version we have and how that package works)
You can't legally claim you're 100% java compatible without risking to be sued
by sun or paying big bucks to sun, and licensing their testing kit and code,
which prevents you from releasing your VM as a free VM.
Kaffe for example states quite prominently on its web page on kaffe.org that
it's not java. If you want 100% java compatible, you want Sun and nothing else.
I doubt that's acceptable for debian, given it's whole social contract idea.
> >>From the Social Contract:
> >"We will support our users who develop and run non-free software on
> >Debian, but we will never make the system depend on an item of non-free
> >software."
>
> Yea, and thats why most of the java packages are in contrib. We have
> also motif software, which is also 'somewhere' in debian.
there is lesstiff to make it free. motif went open source-like as well, though
I don't know if the license is debian-approved.
> Or are you going to file removal requests against motif programms,
> eclipse, tomcat and other java packages?
> What I want is a well defined API, so that our packages can use such
> nonfree JVM. This doesn't mean, that we depend on this non free (apaart
> from the package, which are not working with fre alternatives), but
> that we are open to the fact, that there are other solutions.
there is an API, it's the Java APIs as defined by the java platform API specs.
It does *not* contain such things like how javac interprets -classpath. It just
contains a description of syntax and semantics of all classes available to java
programmers in a particular release.
The problem is all the developers who just want to make things work and use the
rest of the JDK and believe that gives them a right to call it an 'API' ;)
If an application uses anything beyound the java programming APIs, it is not
portable by definition, not even between different releases by Sun. It may work
by sheer luck, but it doesn't have to. As I said, sun has changed their 'API'
to java and javac executables in the past, and I assume they will continue to
do so. Sun also keeps breaking compatibility between java releases, so saying
that a package requires java 1.1 doesn't mean that it will run or run the same
on Sun's java 1.2, 1.3 or 1.4. See Sun's docs for any java release for more
information.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: