Hi Jukka, Hi Jukka, --- Jukka Santala <[EMAIL PROTECTED]> 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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
