[kaffe] KeyEvent -> JDK 1.4 patch (And longer explanation;)

[Dalibor Topic]

Hi Jukka,
Hi Jukka,

--- Jukka Santala <jsantala@morphine.tml.hut.fi>
wrote:
> This patch updates java.awt.event.KeyEvent to
> "sorta" JDK 1.4 spec. This
> mostly involves a bunch of new key type defines, and
> is neccessary because
> Swing for some reason now thinks Kaffe is Java2
> compatible and so tries to
> use them with Kaffe. This implementation has been
> checked with reflection
> etc. to match Sun JDK 1.4.0 and IBM Java 1.3.0.

thanks for your patch, it looks good and should go in.

> Speaking of space savings, this patch adds a
> non-trivial amount of static
> key-defines, as well as code for getKeyText() and
> complexity for
> isActionKey(). I submit that this would be a
> potential case for weighting
> the advantages and costs involved in trying to
> support a JDK specific
> class-lib build system. I think embedded use is
> still oen important
> consideration for Kaffe, and Java2's code-bloat
> doesn't really help with
> it. Unfortunately for decisions inside classes this
> would seem to mean
> some kind of preprocessor with directives.

That's true, full java 2 support with the tons of
classes included would require more memory, which is
unpleasant in the embedded setup. A JDK specific class
build system could help. I see that cutting away
classes should not impose a large problem, but
handling different semantics (like some constants
being only available in Java 2, or differing
method/feature implementations) for different JDK
versions could be really ugly. 

My opinion is that documenting the ways how to reduce
memory usage and class file size in FAQ.embedded
provides great value to embedded developers right now,
but I'd be glad to see a better, automatized approach.


Maybe revising the design of tightly coupled parts of
the implementation could help create a more flexible
runtime library for everyone's benefit. I wouldn't
object to putting AWT in its own jar, for example.
People compiling with awt would recompile awt.jar, the
rest would profit from a smaller rt.jar. What do you
think?

> Another thought while doing the class checkup, I
> noticed that the
> constructor functions do almost exactly same thing,
> but each one has been
> separately typed in there. This is ofcourse good for
> performance, since
> KeyEvent constructors will be called for all
> key-presses etc. and this
> avoids one level of nested calls compared to each
> constructor making call
> to "meta-constructor" with fixed attributes.
> Incidentally though, this is
> use of the same pattern as I've suggested for
> HashMap.find(), which
> several magnitudes more often used than KeyEven
> constructors. Hopefully
> there will be some sort of common guidleine (not
> neccessarily a "rule") on
> the use of code-duplication for performance-critical
> code-paths to avoid
> nested calls.

I guess it depends on the situation: constructors are
unlikely to be manually inlined into other methods, so
the maintainability doesn't suffer that much. Inlining
constructors limits the damage to a small scope ;)

Normal methods are different, in my opinion, as they
can be inlined all over the class, or even outside the
class to save method call overhead. I think that is
bad style, but that's just my opinion. 

I'd prefer to leave that kind of optimization to
bytecode optimizers. My results with running such
tools 6 months ago were promising, but I couldn't get
the optimized Klasses.jar files to run. Things might
have changed in the meantime.

> Speaking of performance tunings, this patch uses a
> touch unconventional
> code for isActionKey(). Optimizers that can optimize
> for expected keyboard
> input are still far, far in the future, so I hope
> nobody objects on "Let's
> optimize this in the VM for all code" to this :)

You commented the code, so it should be quite easy for
others to understand what you're doing in that method.
You could add a few lines saying that you are doing it
for performance reasons, though. If you are out for
maximum performance, you may want to consider using a
boolean array ACTIONKEY with isActionKey value for all
the keyCodes. Then your isActionKey method reduces to:

return ACTIONKEY(keyCode);

excuse the typo in array access, I can't find the
proper braces on the arabic keyboard. 

The implementation is fast, but eats up some memory. I
don't know how many legal keyCodes are possible, so I
can't tell.

> For future work: With j2sdk1.4.0:
> Exception in thread "main"
> java.lang.ExceptionInInitializerError
> Caused by: java.lang.IllegalArgumentException: null
> source
>         at
> java.util.EventObject.<init>(EventObject.java:34)
>         at
> java.awt.AWTEvent.<init>(AWTEvent.java:225)
>         at
>
java.awt.event.ComponentEvent.<init>(ComponentEvent.java:94)
>         at
>
java.awt.event.InputEvent.<init>(InputEvent.java:179)
>         at
> java.awt.event.KeyEvent.<init>(KeyEvent.java:858)
>         at
> java.awt.event.KeyEvent.<init>(KeyEvent.java:914)
>         at
> java.awt.event.KeyEvent.<init>(KeyEvent.java:923)

so this means that KeyEvents with a null source works
in kaffe when it should not?

> And I'll be unlikely to do that work, because this
> patch is enough to get
> our software work with Kaffe ;) (Actually, it's
> fairly lot more than just
> what's needed, since I wanted to make sure all the
> constants were there
> and consistent).

good to hear that xsmiles works with kaffe!

best regards,

dalibor topic

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com