Re-used event objects (was: Re: [kaffe] java.lang.reflect.Method virtual method call bug (CVS))
Benja Fallenstein
b.fallenstein at gmx.de
Sat Dec 28 12:27:58 PST 2002
Benja Fallenstein wrote:
> Not completely; it starts up, but something in our call hierarchy eats
> simple key events like single characters, spaces or returns; more
> complex things like function keys, Tab or PgUp/PgDn are processed
> correctly. We do recieve the events, apparently, but something eats
> them. I haven't seen this on the proprietary JVMs, so I guess there
> must be some kind of incompatibility (trying to process key events
> across Javas is **icky**). I'll tell if I find out what's causing this.
I have isolated the incompatibility: Kaffe re-uses KeyEvent objects;
after issuing a KEY_PRESSED event, it issues a KEY_TYPED event which is
the same object, with a field value changed inside. Interestingly, the
KEY_RELEASED events seem to be separate objects. Gzz implements its own
event queue to coordinate event processing with animation; this is
implemented by putting the KeyEvent objects in a LinkedList. As it
happens, Gzz by default only reacts to KEY_TYPED events, and as it
happens, all three KEY_* events are usually queued before any of them is
processed. This means that at the time we get around to processing the
key events, we have two KEY_TYPED and one KEY_RELEASED event in the
queue (because the original KEY_PRESSED event was changed to KEY_TYPED
by Kaffe).
Gzz might be able to work around this, but I suggest that Kaffe not
re-use KeyEvent objects, as code like the above works fine on the
proprietary Javas and breaks on Kaffe in nonobvious ways. (Caching by
using weak references might be an option, but I wouldn't think it's
worth it...)
- Benja
More information about the kaffe
mailing list