From: Godmar Back (gback@cs.utah.edu)
Date: Tue Feb 09 1999 - 23:02:27 EST
> However, AFAIK, their implementations are much closer to the
> specification than Kaffe's, and that's why I think it would be nice to
> adopt them. Some people that work here at Unicamp with Kaffe and
> Guaranį frequently find bugs in the Kaffe API, and they're not usually
> skilled enough to debug them, so I have to do it or ask them to submit
> bug reports.
>
> Adopting Classpath would have one benefit, which is that of increasing
> the amount of people working on the project, and another expected
> benefit of decreasing the number of bugs in the API implementation.
>
Classpath doesn't even compile most of the time; what makes you think
it's less bug-ridden?
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.
Having documentation is a big plus, but also not that big of a deal cause
most of it is available from Sun, and most java classes are not that
complex that you couldn't understand the implementation of private methods
even when you have doc for the public methods.
>
> 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.
>
> > However, I would personally like it if donating code to kaffe is an
> > act that does not restrict your ownership of that code in any way,
> > which is not (quite as) true for classpath or other FSF-sponsored
> > projects, because of the FSF's agenda for what they call "social
> > engineering".
>
> 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.
> > Also, Tim & Peter have donated their disk space, reputation, man
> > power and webspace for the public VM so far *without* being able to
> > sell the efforts you or I put into it. I don't want this to be
> > forgotten, just as you should not forget that Kaffe wouldn't exist
> > without Tim's effort at all.
>
> I'd never forget that. He's made my MSc work possible (or at least
> much easier), and he deserved a personal acknowledgment for that in my
> Master Thesis (if that's worth anything :-)
>
> Also, I understand that he's spent quite a lot of time implementing
> the existing Java Core API for Kaffe, but most of the work was put in
> the virtual machine, which I find great, while the API implementation
> was done in a hurry (AFAIK). 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.
What's a lot more important is how well tested it is, and there I
don't see a big advantage for them. (Did they test certain parts
at all? If so, how did they test the things that cause problems at the
moment, like serialization? I think they didn't. I still have to
see a single bug report of a real application on the classpath
mailing list.)
The other issue is the native part of java.*. I looked at Japhar some,
and there's no way they'll get to where we already are any time soon.
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. Plus, the problems and performance issues we already
discussed with JNI, which is what classpath uses.
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. I already know who'll
own the automake build system package.
>
> That's why I'd like us to adopt it, if Tim and Peter would agree with
> it. If they do not, that's fine, I'm not going to branch off Kaffe
> (although I have already done, for Guaranį :-), nor am I going to stop
> contributing to it, because I really value the work Tim and Peter have
> done.
>
That's great, because besides fucking with automake there's really
great things you could do for Kaffe. 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. This would give Kaffe a real edge.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:04 EDT