Re: Proposal: merge Jessie as an external project

[Archie Cobbs]

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.

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.

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.

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 (!)

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. If you want the full monty, it's easy to put
that together, but don't force it on every one.

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com