Re-used event objects (was: Re: [kaffe] java.lang.reflect.Method virtual method call bug (CVS))

Benja Fallenstein b.fallenstein at
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