JFORK: Or a reasonable response to the Sun SCSL
Ean R . Schuessler writes:
> It is now clear to me that Sun is engaging in one of the most
> effective attempts to hijack the tenets of the free software movement
> to date.
Agreed. It is a logical progression of their 1995 marketing
strategy, which has been extraordinarily successful in
drawing in coders from the very first days.
> JFORK
> The other obvious imperitave of a fork is that it must maintain the
> chief element that has made Java popular, portability. Interoperation
> with the existing VMs must be made as universal as possible, both
> through compliance with Sun standards where possible and through the
> availablility of either pure Java or highly portable implementations
> of any system extensions.
I'd like to add a few observations to this. In particular:
shouldn't a "strip" preceed any "fork". Java started as
three components: a C++ like language definition (which
could well be compiled to native code), a VM which operates
on bytecode (which does not have to be generated from Java),
and a set of classes, only a small part of which is actually
mandatory for implementing the language definition.
Since then, Java has been bloated to become the be-all, end-all
leverage in API wars on all fronts. A particular gripe of mine
is the unwillingness of Sun to support OpenGL by official
bindings despite it being *the* one cross platform API. I
have been on the early java3d mailing list in 1995, and I
very well remember statements made there. Instead we get
Java3D, which to me looks like an ill-conceived scene graph
API rushed to the market.
During my brief contemplations of OpenGL, JNI, AWT, and Java,
I have also heard comments from coders interested in imaging
which outright rejected the AWT design to be capable of any
worthwhile use for their purposes. I personally fail to see
why AGBR was chosen. There are also issues some of which are
now supposed to be solved by a newly AWT Native Interface,
which, to my understanding, affected Swing and Java3D just
as much as they did e.g. Magician.
I take AWT as a point in case. I don't know how well
designed Servlets and Jini and... are, but I for one
think that JFORK faces a loose-loose situation between
trying to appease the developers that rush to use every
Java API ever invented, and keeping step with Sun's
latest shenanigans and revisions.
The key to free Java is modesty. Open source has the one
big advantage that our native code is portable. If we
waste our time implementing every spec Sun dishes out to
occupy mindshare, we might miss out the chance to provide
a better designed alternative. I'd rather see portable
GL bindings then a Java3D implementation that fills the
WORA gap whereever Sun doesn't deliver.
> Perhaps we can solidify them a bit and make a move
> to a more complete picture of a free java.
I guess that this will drive even more people away from
Debian/Linux. I also wonder whether this is the right
step to take. Obviously, the public awareness for the
implications of the SCSL has to be increased. Yet, JFORK
seems the wrong step: it will just give Sun ammunition to
point at the effort and state: this splintering is what
the SCSL was meant to prevent. In fact, what we want to
remind the public of is that the SCSL, combined with
Sun's public stance on clean room (Baratz: looking at
the specs is using Sun's intellectual property) and the
possible leverage of patents is meant to hamper and prevent
any conformant free implementation. The same is true for
compliance tests - see Mauve.
When I argued for the integration of small Java commandline
tools with the Linux native environment early this year,
I set myself a simple goal: a pure Java built environment
with tar, make, dependency, find, that could create
itself from the sources given just a JRE (I called it
Jinx after a while, for various reasons). I think that
free Java will come into being starting at the beginnings,
and determining the essentials: the VM, the language,
the true core of the "core" classes. The fork will occur
when we determine what's really missing from the true core.
It will be a long time till free Java will have anything
to offer to those who want, or just have, to use the latest
and greatest of Sun's Many Volatile Standards. But then,
we are not paid to do so.
b.
Reply to: