From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Tue Feb 09 1999 - 23:54:29 EST
On Feb 10, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>> 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?
Probably wishful thinking :-)
> 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. :-(
>> 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.
>> 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.
>> 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
> 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 :-(
> 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.
> I already know who'll own the automake build system package.
:-D
As a side note, I've had some ideas on an incremental build system for
Java (i.e., rebuilding a class whenever its source or any other
dependency has changed), but I don't know when I'll have time to
implement it :-(
> 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 :-(
> This would give Kaffe a real edge.
Yep :-)
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:04 EDT