Re: [Kaffe] can the classpath project be used with Kaffe. (fwd)

Date view Thread view Subject view Author view

From: Tim Wilkinson (tim@transvirtual.com)
Date: Wed Feb 10 1999 - 17:31:07 EST


Alexandre,

> On Feb 10, 1999, Tim Wilkinson <tim@transvirtual.com> wrote:
>
> > - my Custom customers don't want to screw around with untested and
> > legally illiterate licenses
>
> If you were willing to test and support (the parts of) Classpath (that
> we would adopt), that would not be a problem at all. But I understand
> your willingness not to do it.

You missed the last point - we work on the libraries because we have
customers that use them. If these customers were true open source people
then there'd be no issue - but they're not and they're not prepared to work
with the GPL or the LGPL. If any of classpath was adopted in kaffe it would
be without any support from TVT since we have tend to work in areas where we
have customers.

> > Are you really saying that the solution to bugs in our libraries is to
> > throw them away and use someone elses - hey! if we have a bug in the VM
> > we should chuck that out too and use Japhar - what do you say !! :-)
>
> A very good analogy. But my point is not about throwing someone's
> work away, actually, it's about sharing efforts, picking up what's
> best in Classpath and adopting it in Kaffe, even if that means
> discarding some code we may have written.
>
> If we could *selectively* adopt Classpath, it would be great.

Dunno about sharing since we cannot give any of kaffe's libraries to
Classpath since they want the copyright to go to the FSF (and we won't do
that). What 'selective' bits of Classpath did you want to use anyway?

> It is true that they put great emphasis on complying with the
     spec as
> far as the gestalt of their public interfaces is concerned; we
     need to do
> the same for kaffe. I see this as rather minor.

     I don't think it's minor when a program some of my colleagues run
     on
     JDK fails to run on Kaffe. :-(

Then we fix the bugs - what so wrong with that exactly?

>> I agree. Nevertheless, they have evolved much faster than us,
     and I
>> don't expect this to change in the near future :-( So, now,
     we're the
>> ones duplicating the effort :-(

> I disagree. I'm on the mailing list too, and they're not moving
     that
> fast. It's just that they get volunteers because they've had
> advertisements out, which we don't.

     There are frequent postings to the Classpath mailing list from
     people
     willing to contribute some code, but I've never seen such a
     posting to
     the Kaffe mailing list. If making more publicity on Kaffe will
     get us
     that, it's great! If not, adopting Classpath might mean faster
     progress.

In the time I've been doing Kaffe I've had numerous offers of libraries,
help, ports and so forth - and almost without exception absolutely nothing
has come of them - possibly this is my fault but I'm not sure how to manage
this better (while running TVT as well).

>> If we adopted Classpath, we could keep local modifications
     contributed
>> from people not willing to assign their code to FSF. It might
     make
>> regular merges harder, but then, I believe Tim has a hard time
>> whenever he tries to merge his sourcebase with Kaffe's, and the
     only
>> effect of adopting Classpath's version would be that he could
     share
>> part of that job with someone else.

> The other effect would be that he would not be able to
     contribute
> to Kaffe anymore.

     Of course he could: we can modify any code we copy from Classpath.

     The point is whether TVT is willing to use that code in the Custom

     Edition too or not, and I think they're inclined not to do it.

We can't - I've given the reasons why not. But anyway what your proposing
is to fork classpath off into Kaffe, and of course Kaffe will be forked
because out custom work can't be folded back in the the desktop.

>> I believe Classpath's implementations are more complete,
     because
>> they're not done under so much pressure, and they seem to be
     very
>> careful about *full* compliance.

> The compliance at this point is only in the interfaces.
> Yes, they have scripts that check that the public methods of
     their
> implementation match Sun's. That's good, but it's no big deal.

     I was under the impression that it was more thoroughly tested,
     but, as
     I said, this is probably just wishful thinking

Testing is a big issue and something we've addressing here - we recently
hired a guy to do QA for us so we've hoping to improve this.

> If so, how did they test the things that cause problems at the
> moment, like serialization?

     Now that you mention serialization, one of their important
     decisions
     was to implement classes that were serialization-compatible with
     Sun's
     implementation (but that code that may be untested too). We'd
     have to
     spend quite a lot of time in re-doing what they've already done
     :-(

Define a lot of time - I think I've spent more time on this conversation
than I did rewriting serialiazation :)

> I spent a great amount of time getting java.lang.ClassLoader
     right
> according to Sun's spec and Gilad Bracha's implementation, work
     I don't
> want to duplicate.

     You wouldn't have to duplicate it. If Classpath's ClassLoader
     isn't
     compatible with our code, we don't have to use it.

> Plus, the problems and performance issues we already discussed
     with
> JNI, which is what classpath uses.

     We don't have to use JNI for our native implementations.

> What they do differently is that the assign "package
     maintainers"
> for packages. This may give some contributors a greater feeling
     of
> ownership. We should consider something similar.

     Yep, that would be cool.

> For instance, one thing that Tim doesn't currently have the time
     to
> do, but for which your skill set puts you in a formidable
     position
> (I mean really), is to get the egcs front-end to run with Kaffe.

     I'm not sure I'm skilled enough to do that. I have never been
     able to
     learn enough about the internals of gcc :-(

     But I may find time to do it, it shouldn't be that hard. It would
     be
     still better to be able to use egcs' front-end and back-end as a
     just-in-time compiler. I already have some ideas on that, but I
     doubt
     I'll ever have enough time to evolve them into anything usable :-(

Argh! GCCs back end as JIT - my god the tradeoffs are so wrong I hate to
think how bad that could be. Actually I should just fold in the GCJ stuff
I have and see how well it works - I need to update it (perhaps I should do
that tomorrow).

> This would give Kaffe a real edge.

     Yep :-)

It definately would

Tim

--
  Tim Wilkinson                         Tel:     +1 510 704 1660
  Transvirtual Technologies, Inc.,      Fax:     +1 510 704 1893
  Berkeley, CA, USA.                    Email:   tim@transvirtual.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:05 EDT