Re: [gentoo-java] Java going GPL; Stallman approves -- News at 11:00

[Karl Trygve Kalleberg]

Hi David

> The jdk-distros project is meant to be a staging ground for some of the
> linux-specific bits and documentation.  However it's focused entirely on
> installers, and not the JDK code itself.  The jdk-distros project uses
> the BSD license to facilitate even more fluid code sharing.
>
> You are probably talking about source changes, not installer changes..?

Yes, I am referring to inevitable patches required to get the JDK built
from source code, since that is what we want to do as soon as we can get
around to it -- build the JDK from source code instead of using the
Sun-provided DLJ binaries (of course, first all of the JDK must be
there, c.f. the encumbered parts of the library).

In the past, we had a from-source ebuild for the JDK, but given the
(old!) licensing conditions, none of the current Gentoo Java developers
wanted to become contaminated by looking at the JDK source (this is now
a thing of the past! waaaay!). In our from-source ebuild, we did various
patching (I don't know the specifics) of the JDK source to get it built
on Gentoo.

Similarly, for Eclipse, we've had to do all kind of strange code
acrobatics to get it compiling even remotely properly on Linux. Over the
years, Eclipse has been able to use the Motif and Gtk+ windowing
toolkits, the GNOME and KDE VFS, the Mozilla embedded browser component
(libgtkembedmoz), and it has been rather picky about which Java
compilers and JDKs it will build with. Since Eclipse doesn't use
autoconf and friends, and some of the build paths have even been
hardcoded to fixed paths in their buildfarm, it's sometimes been a bit
icky to get everything compiling smoothly for our users.

Take the example of the embedded HTML component in Eclipse, which uses
the Gecko rendering engine. Upstream, this component has historically
either been built against the Gecko SDK or one of the Mozilla 1.x stable
branch, but upstream doesn't maintain compatibility for both. So, we've
had to patch in support for compiling Eclipse on systems where only
Firefox is installed (and this is possible, even though the label
advises against it;).

Since I've not yet familiarized myself with the JDK source base, I
cannot offer specific examples of where we would need to patch your
build scripts, but I am sure we'll run into something pretty quickly,
and so will the Debian, Fedora, OpenSUSE and Ubuntu guys, I am sure.

> The current contribution process is a work in progress and we know it's
> not the final one.  We plan to develop a better contribution process
> over time.  The process that's there is very similar to the process we
> use in-house that Sun engineers go through on every change we make to
> Java SE.  We take stability as a very high attribute and the process we
> follow involves a lot of peer review and unit/etc testing before it is
> allowed into the central source repository.

That is perfectly understandable, and I would have it no other way. Your
goal is to ship stable products and be the primary care takers of the
JDK code base.

What we need is a place and a forum where we can share build system
patches and fixes (and sometimes, the patches may affect more than just
the build system -- even you guys make a few mistakes and incorrect
assumptions in your code now and again;).

> But, that said, any future contribution process is open for discussion.
> The appropriate place to take that is the mailing lists and/or forums on
> java.net.
>
> We are open to, in the future, having external contributors with direct
> putback rights.  And that, too, is a topic for discussion.

I think I should be clear that I'm not asking for you to loosen your
standards when it comes to the commit privileges on the OpenJDK
repository. I do see the need for an arena with a code repo, a wiki, a
mailing list where the JDK packagers on the various distros can share
code, ideas, gripes and experience.

> BTW, one goal for the jdk-distros project was for it to hold the
> installer scripts for each distribution using the DLJ.  The
> Debian/Ubuntu scripts are in the jdk-distros repository.  The Gentoo
> scripts could be, if you desire, if there is any need for it.

The jdk-distros project may indeed be exactly what we're looking for
here. I don't think that there's any point in us putting our ebuilds
into this repo, however, because they would grow stale in a matter of
days -- as you know, we try to maintain all our installation scripts
(i.e. ebuilds) in the Portage tree, so that they're always and instantly
available to our users.

Any patches and fixes that we eventually apply to the JDK built system,
however, are candidates for inclusion into jdk-distros.

> The purpose was along the lines of what you have discussed.  To
> facilitate sharing between the distribution makers of the installation
> procedures.

Perhaps expanding the mandate for jdk-distros is useful, then, to also
include build system patches for the OpenJDK.

Since Gentoo is "from source"-outfit, our focus will shift towards
source drops of the JDK as these become available (hopefully some time
next year) and Java 1.7 draws closer to a release. I anticipate that we
will keep Sun-provided binaries for 1.5, 1.6 and 1.7, and probably even
future versions in the years to come, but our priority has always been
and will always be source-based packages.

(But I'm not the cat-herder around here anymore, so my thoughts on the
binary/source issue are just speculations based on hard-earned
experience, and should not be taken as any official statement on behalf
of the Gentoo Java Team.)


Cheers,

-- Karl T
-- 
gentoo-java@g.o mailing list