Re: Proposal: merge Jessie as an external project

[Archie Cobbs]

Thomas Fitzsimmons wrote:
> > 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.

What you're saying makes sense from the "packaging" point of view.
I.e., I agree that it's nice to be able to download one thing and
get the complete package. There should be a "JDK equivalent" in free
software.

However it doesn't make as much sense from the developer's point of
view. Classpath developers (I assume) want to focus on Classpath, not
on maintaining Makefiles and 3rd party code build integration. Not to
mention that some users of Classpath don't want all the extra junk,
e.g., people targeting embedded systems.

I guess then what I'm arguing for is that maybe Classpath should be
split into multiple projects: one to produce the "core core" Classpath
code (i.e., the code that lives as source code in Classpath's CVS
and originates there), and others to produce a "JRE equivalent"
(which includes Classpath, Jessie, Xerces, etc) and perhaps a
"JDK equivalent" (which inludes as well a java compiler, etc.).

I'm looking at Classpath as the former type of thing whereas you are
looking at it as the latter type of thing. As Classpath exists right now
it seems a lot more like the former. Instead of trying to morph it into
a JDK/JRE replacement, let's create a separate project to do that.

I'm curious what other Classpath developers think...

-Archie

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