From: Godmar Back (gback@cs.utah.edu)
Date: Sun Dec 13 1998 - 14:34:07 EST
>
> > I checked in what I think.
>
> It does not look like you're open for discussion, but I'll assume you
> didn't mean it.
Okay, that sounded a bit a harsh.
I apologize. I really want the interpersonal relationships between
kaffe-core as tension free and warm as possible.
>
> Since we're trying to optimize things, I thought we could save two
> method invocations here, and having an additional header file doesn't
> look like an expensive price for that to me.
In my opinion, Amdahl's Law tells us that we shouldn't focus our
optimization efforts on thread finalization.
>
> > I'm aware that Sun does some trickery (i.e., create a package access
> > method), but hey, given that Kaffe currently does even check public,
> > private, etc., don't you think we could live with that for a while?
>
> The point is not about checking, the point is that any Java-compliant
> compiler *will* generate the additional wrapper method, and will
> invoke it instead of the one you intended to invoke directly. Go
> figure it out like I did.
I didn't realize that your motivation was to save a function call,
I thought your motivation was cleanness in the sense that no outside
entity should be able to invoke Thread.finalize0 maliciously,
which could happen if there was a package access method.
>
> > We'd save one header file, one class file, and a lot of confusion.
>
> I agree with the confusion introduced by dollars in identifiers, but I
> don't think the additional class or header files are an issue.
>
> I'll make another try with a top-level class, to avoid the `$'s.
>
> Next time, if you find some problem, please don't just undo the
> changes without discussion (or even silently, like you did a few days
> ago :-(, this doesn't improve cooperation at all; you can easily check
> out the previous version and use it while we discuss an issue.
>
Please remind me what I silently undid a few days ago.
I honestly don't remember what that was. Was is the #include
"config-mem.h" in clr.c? That really was an oversight.
It did break the compile on FreeBSD, but you're right, I must have not
been paying attention. The proper fix is of course to also include
"config-std.h" (although I'm not sure if that's how it ought to be.)
> > I think that at some point, Sun will solve the problems with inner
> > classes somehow, and then we'll have to implement their solution anyway.
>
> I don't think there's anything to solve here.
>
Yes there is. If you have a private anonymous inner class, then you
don't want any method with package access manipulating it.
Sun realized at some point that the way they did inner classes was
incompatible with the protection mechanism in the JVM spec, and to my
knowledge this problem is still open.
I'll see if I can find a URL that discusses this.
Could we could get the opinions of other team members on the Thread.finalize
issue.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:14 EDT