Bug#212863: new java policy: ok or not?
In message: <[🔎] 20031015160432.GB10785@katzien.de>
Jan Schulz <jasc.usenet@gmx.de> writes:
[a minor rant about how there's not much progress on Java in Debian]
I don't anything particularly useful to reply to the points that Jan
makes, largely because I've given up on Java per se as part of Debian.
There's a very fundamental reason for this: Debian is about free
software, and Java is not free.
Don't get me wrong; free things can be made with Java, just as they
can be with any other language... and once compiled (preferably to
native code) they can be distributed just like any other free code.
They have dependencies which need to be fulfilled to run (libraries,
VMs, what have you), and those can also be handled in all the normal
ways. We don't need a special policy for that.
The only complication for Java really is in this odd idea that you
should be able to run bytecode designed for one VM in a different
VM... and that somehow we as designers of the Debian system ought
to support this idea. Yes, I know that various vendors have hyped
this idea a lot, but the various VM incompatibilities that have
turned up in discussion reveal the relative unworkability of this
idea. It's like asking code to work under Windows and Linux and
AIX and MacOS 9 all at the same time... for simple stuff, it's no
big deal, but as soon as you try to use any advanced features of
any environment (like file-locking, perhaps), compatibility with
the other environments pretty much vanishes (unless you have
separate code for each environment, which is a maintenance
nightmare).
The whole reason we're even having this discussion is that people
find it unpalatable to install multiple VMs because different
packages that they've installed prefer different environments.
After watching the arguments and learning of the difficulties,
I just say "get over it". Guess what? If you have programs
written in csh and bash and ksh, then you have to install multiple
shells. The same is basically true of Java: if you have programs
written for kaffe and for sablevm and for Sun's Java, then you
have to install multiple VMs. Trying to convince programs to run
in a non-preferred environment is just asking for pain.
Java libraries are perhaps a sticking point; most people won't
want to install a separate version of xerces or cryptix for each
and every VM. However, once we dispense with this notion of
trying to make programs run under any VM, then libraries can just
be installed int some well known directory, and the programs can
include all the appropriate things in their classpaths without
difficulty. It's trying to make the classpath generation generic
that complicates things.
So no, I don't think we need the sorts of changes to the Java
Policy that have been proposed. I think we ought to define a
library location, specify that programs should have wrappers
to invoke a package-preferred VM with a workable classpath, and
leave the rest up to standard policy and dependency handling.
If a package wants to support multiple VMs, that's fine... but
the differences are great enough that I can't imagine any end-user
packages actually doing so.
This all wouldn't be an issue if the primary implementation (Sun's)
was free software... then we wouldn't have any more difficulty
than perl, as an example. But that's not the case for Java, and
the fracturing of the execution environment that results from
having multiple competing implementations makes it completely
unrealistic to treat Java as a plug-and-play environment where
the end user can pick and choose base components without affecting
the things they put on top of it.
- Alex
Reply to: