From: Godmar Back (gback@cs.utah.edu)
Date: Thu Feb 11 1999 - 11:34:20 EST
>
> I'm not saying you have to spend all day writing e-mail with `Cool',
> `I love that idea' or `This improvement would be welcome' (we all can
> do that :-), I'm just trying to explain why I, and possibly others,
> have non contributed to Kaffe as much as we could. Now there are
> several people in the Kaffe Core that can welcome new contributors,
> and we can share the load of this kind of personal management with
> you. But it would be nice if you could still take some part of that,
> because people like to know that the ``king'' :-) is paying
> attention.
>
There's some truth to it, Tim.
Btw, I'm half done with my www.kaffe.org pages. I'll point you guys to
them may tonight or tomorrow and then I'd like you to give me feedback.
> Just my R$ 0,02 (no dollars, sorry, I'm saving :-)
>
> > 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.
>
> Great! BTW, I was wondering whether we should convert all our tests
> to the Mauve framework and start testing Kaffe with Mauve regularly,
> instead of, again, duplicating the effort.
>
We need to do both. Mauve does not test VM stuff; they've clearly said
they won't. We must contribute and encourage people to contribute
testcases to mauve (in fact Tim has said TVT will do that), but we still
need our testcases for the VM. I've written a lot of them, and believe me
I know what I'm talking about.
>
> As you probably already know, compatibility with JDK in terms of
> Serialization is not just a matter of the wire protocol: default
> serialization won't do for classes that don't have exactly the same
> structure, so, in clean-room implementations, any Serializable code
> that wishes to remain compatible with Sun's must explicitly define the
> class serial ID and implement read/writeObjectState methods, writing
> the fields exactly as specified by Sun. I believe Classpath has
> already done that, based on their previous discussions on this
> subject, but, again, I may be wrong.
Alexandre, what do you think Tim was talking about all the time?
That's what his inner classes are for.
>
> > Argh! GCCs back end as JIT - my god the tradeoffs are so wrong I hate to
> > think how bad that could be.
>
> Yep, I know it would be ridiculous to use it as the only JIT, but I
> was thinking of using it as a background JIT, with a cache, keeping
> current JIT (or even the interpreter) to run a method's code before
> the background JIT does its job.
Fine fine.
There's even people at Microsoft who want to use VC++'s backend as a JIT.
Really, I just talked to a VC++ developer yesterday.
But the short term promise is and remains gcj.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:05 EDT