I think the Debian Java policy, as currently stated, is slightly flawed,
as it tries to satisfy two goals that aren't completely orthogonal:
1) To get as much free Java software into Debian as possible, that runs
without non-free software (eg. without Sun's JDK)
2) To put together a distribution that works out-of-the-box with
multiple free JVM and class library implementations (as well as
proprietary JVM implementations).
They are both worthy goals, but ultimately, in order to get something
that works nicely, I think we need something else - our own set of
specifications.
Because the set of Java APIs is so large, trying to develop a set of
class libraries that works as a drop in replacement for Sun's libraries
is a very large task. In reality, it's going to be a long time before
the free java class library projects manage to reimplement 100% of the
Java2 API, and it's a moving target. In many cases, the "official" API
isn't so nice, and there are better free alternatives, so there isn't a
lot of motivation for individual developers to reimplement the
"official" API.
There are multiple free implementations of the Java class libraries out
there. It would be nice if they were all merged into one, but that's
unlikely to ever happen for legal/business reasons. Having multiple
implementations is a nice problem to have however (as opposed to having
no implementations).
If we introduce software into Debian that runs on one implementation
(eg. Kaffe), but not on another (eg. gcj), then we are introducing
breakage. What do we do in that case? Do we hold back software unless
it runs on all the JVMs/class libraries in Debian? Or do we introduce
the software as soon as it runs on just one JVM in Debian (and breaks on
all the others).
I think part of the problem is that there isn't enough granularity in
Sun's Java specifications to make it easy for free software JVM/class
library implementors to implement the whole thing (eg. "J2SE or J2EE").
Sun has broken the API up a bit for J2ME applications (eg. CLDC, CDC,
MIDP, Foundation profile, etc.), just because Java2 won't fit in a
cellphone or settop box. But in general, for desktop applications, Sun
encourages developers to use the full set of APIs that they have thrown
into the box along with their JDK.
I think it would be incredibly useful if we, as the free software
community, came up with our own set of specs for Java, documenting and
advocating which APIs we feel are appropriate to use (based on the
availability of free software implementations).
Now there's a danger there - Sun is very protective of their control
over the Java language and APIs. They don't want somebody else to take
control of their spec. They've got a lot of lawyers. They wrap all of
their agreements in nasty legal clauses which basically forbid anybody
from extending or changing their APIs, which is naturally incompatible
with free software licensing models.
I'm not proposing that we try to come up with a competing set of specs
and alternate vision for Java. I just think it would be useful if we
could document subsets of APIs that free JVM/class library people have
implemented (or could implement), and publish those so that people
writing free software Java applications and libraries would know which
APIs they should use if they want their software to run on which free
JVM. And it would be nice if we published these specs in such a way
that they were free from the legal restrictions Sun has put on their own
specifications.
The specs could define their own set of configurations and profiles free
from Sun's marketing lingo (eg. akin to J2ME, J2SE, J2EE, CDC, CLDC,
MIDP, but more granular, and more matched to what the free software
community currently have). In many cases, the APIs that Sun has
introduced into the Java2 platform are just renamed and reimplemented
versions of stuff that already existed as free software (eg. log4j,
regex functionality). Until we reimplement those same functionalities
to conform to Sun's APIs, it would be nice to be able to steer free
software authors toward the free third party APIs. Again, that might
anger Sun.
We could also draw up specs for interoperability between the various
free JVMs out there (eg. alternate native method interfaces such as CNI,
gcj ABI, ORP JIT/GC interfaces, verifier interfaces, etc.).
How would Debian use these specs? Applications would be able to declare
dependencies on specific configurations and profiles in the spec.
Virtual machine/class library combinations would be able to declare
which set of configurations and profiles they support. If an
application uses a particular spec, and fails to run on a particular
implementation, then it's a bug in the implementation, so the
application could still go into Debian, and the JVM/class library
implementation would get the bug report so they could fix the problem.
Now, I want to essentially do this work anyways, as part of documenting
Kaffe and it's class libraries, and trying to pull in elements of
Classpath, libgcj, ORP, etc. So you've got a volunteer. :-)
I'd like to see it done as a standalone specification, useful to the
free software community, which doesn't depend on Sun's specification.
Again, that might anger Sun, even if the specification doesn't diverge
from their specification. So it would be nice to have an established
free software project "stand up" for the spec, and publish it for us.
Somebody like Debian, or the GNU project, or perhaps Apache or maybe
even FreeStandards.org. Theoretically, I suspect even the JCP could be
used to host such a project, right under Sun's nose, but I suspect that
there would be issues with the whole premise of the project (to promote
free software implementations and APIs that in some cases, compete with
Sun's offerings).
So, what do people think?
Cheers,
- Jim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
