Re: Proposal: merge Jessie as an external project

[Thomas Fitzsimmons]

On Wed, 2005-04-27 at 16:14 -0500, Archie Cobbs wrote:
> Thomas Fitzsimmons wrote:
> > I propose that we build Jessie directly into glibj.zip.  Having Jessie
> > present by default would be convenient both for GNU Classpath developers
> > and also for packagers.
> > 
> > For GNU Classpath developers who want to test apps that require SSL, it
> > would mean one less dependency to fetch and setup on CLASSPATH.
> > 
> > For packagers obviously it would mean one less package to maintain.
> > More importantly though, it would eliminate a circular dependency.  In
> > Fedora Core 4, for example we want a Java SSL provider available by
> > default.  This means that ideally the libgcj package should depend on
> > the Jessie package.  But Jessie's build requires libgcj.  We worked
> > around this by having java-gcj-compat depend on both libgcj and Jessie,
> > and packages requiring a Java SSL provider requiring java-gcj-compat.
> > However in my opinion this complexity is unwarranted especially given
> > that Jessie's SSL provider jar is only 350K.
> 
> Not to be a contrarian, but in general I don't like the idea of
> glomming in more and more libraries together like this. I'll try to
> emit some coherent reasons why...
> 
> First, you are looking for a workaround to a dependency problem which
> is not of Classpath's making. "Ideally the libgcj package should depend
> on the Jessie package" -- perhaps that's true for Fedora, but if so it's
> because of a Fedora policy decision. That policy should be encapsulated
> in the Fedora build, not the Classpath build.
> 

I guess part of my proposal is that Classpath adopt the same policy (see
below).

> If Classpath wants to help users to have a good experience, we can
> point them at the relevant external 3rd party libraries to go fetch.
> 

But then the experience isn't as good as it could be, since there are
extra steps involved in producing an SSL-enabled Classpath build.

> Secondly, there are good solutions out there to the JAR interdependency
> problem, namely Jpackage. Jpackage can eliminate the habit of every
> Java project shipping every other Java project's JAR files in its lib/
> subdirectory.. invariably you end up with a zillion copies of the same
> JAR (e.g., xerces and xalan) but different (often incompatible) versions.
> 

Yes, we use the JPackage conventions in Fedora; in fact, this proposal
will help us implement them more faithfully (again, see below).

> Thirdly, there's the inevitable maintenance problem with having a copy
> of somebody else's code lying around.. it always goes out of date, becomes
> incompatible, etc. E.g., if my boot loader is loading an old, broken
> version of Jessie, just putting the new one in my (application) classpath
> won't work.. I have to perform surgery on my boot loader classpath.
> This actually happened to me with Sun's JDK because Sun ships an old,
> broken version of Xerces in their rt.jar (!)
> 

This problem exists no matter where Jessie resides.  For a core piece of
infrastructure like Jessie, I'd rather see its integration with
Classpath tested by the wider Classpath community than just tested
downstream by packagers.

> Finally (and this is only obliquely related), Classpath does not depend
> on libgcj. It builds just fine using Jikes... so don't assume they always
> go together. For example, I never use gjc (preferring JC of course :-)
> 
> Classpath should (IMHO) simply be an implementation of the core Java
> classes, nothing more.

I agree fully and that's the point of this proposal.  SSL support is
part of the "core Java classes" and that's why integrating Jessie into
Classpath is different than integrating, say Java-GNOME.  Sun's SDK
includes an SSL implementation.  They happen to ship it as a jar that is
separate from rt.jar but it is still included on the boot classpath.
The important point is that a JPackage SDK RPM includes an SSL
implementation, with no external dependencies.  We could simulate this
in Fedora but in our RPM we'd need to carry a local patch that did the
import I'm proposing.  It's much more efficient to maintain this import
upstream.

I would argue that in general, Classpath's policy should be to include
anything that's in Sun's SDK by default.   For things like image and
protocol providers I think we should strive to include more than Sun by
default.  For example, as both a Classpath developer and end-user, I'd
much rather have the ability to read and write any image format by
default.  I don't want to have to search around for external plugins to
build and install.

>  If you want the full monty, it's easy to put
> that together, but don't force it on every one.
> 

I consider the full monty to be all Free Software written in the Java
programming language.  For stuff above the SDK, definitely, split it
into separate packages.  But for the SDK, our implementation should be
at least as convenient out-of-the-box as Sun's.

Tom