Classpath and Kaffe

Stuart Ballard kaffe@rufus.w3.org
Thu, 29 Jun 2000 09:32:22 -0400


"Aaron M. Renn" wrote:
> 
> I don't think it's entirely fair to say that Kaffe's libraries are designed
> for Kaffe only.  The vast bulk of the code is fairly generic and the
> Kaffe libs could probably be ported to another VM about as easy as the
> Classpath ones.

Oops, yes, I should have been more clear about what I meant by that. I
meant to refer only to the parts that have to interact with the VM, like
most of java.lang and java.lang.reflect, etc...

> The Classpath GPL+exception is actually a step backwards as far as
> Kaffe compatibility goes.  It is even more liberal than the LGPL. I
> doubt Transvirtual would want their code subject to that license where
> it would be very easy to incorporate it into proprietary programs without
> payment.

I know :(

> However, I'm guessing that if some part of the library code was
> built to be shared between the two, TVT wouldn't be dead set against
> the more liberal license.  That's only my guess though and I'm sure it
> would depend on the circumstances.

Do you think it is worth specifically looking through the APIs for
places where this applies - since Classpath is merging with libgcj
anyway at this time? It'd be great if we could see co-operation between
the projects on some parts of the API, even if not all.

I'd think that the places where there's most to gain from co-operation
would be in areas where the design of the solution is well-understood,
but there's a lot of code. In these cases if you have two different
implementations they'll likely be very similar, but have two different
sets of bugs - pretty pointless and it'll take twice as long for bugs to
be fixed because each one only has half the eyes on it. Also in these
cases TVT has less to gain by keeping its version to itself, because
solutions to these cases commoditize easily.

In areas where the design of the solution is more open-ended, there's
less of a benefit from merging because the designs might not merge well;
plus, this is where TVT's 'competitive advantage' comes in.

I think the "core" core libraries seem to fall under the first case -
j.io, j.net, j.util, etc... the AWT is a clear example of the second
case, and other libraries fall somewhere in between, perhaps.

Well, I think I spent over 2c...
Stuart.