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

[Jukka Santala]

On Fri, 4 Oct 2002, Dalibor Topic wrote:
> 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

As a sorta-related issue, I note that Kaffe.org's version takes lots more
space than the Transvirtual custom edition ever did. Part of it may be
because they made off with things like serialization, but I'm wondering if
anybody has an idea where most of the bloat is coming from, and if we can
cut down on it? I'll try to look at that myself at some point, especially
as I can't offhand remember the exact stats and compiling... it may be
just having X-Windows interface instead of framebuffer contributes some.

> 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.

JavaDoc already has its format for specifying which methods and constants
were implemented in which version. I briefly thought it might be simple to
just use those as indications of what should be stripped for specific
level implementation. Unfortunately, I quickly reasoned that alone
wouldn't do it ;) This doesn't mean we couldn't use some JavaDoc like
system to mark up segments that are specific Java2 bloat.

It wouldn't have to catch all Java2 additions, just the most
resource-hungry (and possibly those needed because of totally cut-off
classes - unless you want to use reflection a lot...) ones where somebody
has bothered to do this (for obivious gains). Same format could be
extended to provide automatic selection of class-files for the subsets, as
well as defining subsets other than the obivious JDK version levels - such
as the different JME profiles and possible custom sets.

Problem is, what marking convention should we settle on? Suggestions?


> 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?

That's a good idea, but see above... Altough for AWT we have fairly
straight-forward selector concept in existence already (Just grab the awt
subhierarchy). I can only speak for myself, ofcourse, but I think AWT is
one of the less useful pieces to have separately, despite it being fairly
large in all (with the native support included), because applications tend
to rely on it anyway (embedded graphics) or else have resources to drag it
along (Java servlets etc.). Doing clear-cut jar division on other aspects
of Java API is harder, but see above.

> I guess it depends on the situation: constructors are
> unlikely to be manually inlined into other methods, so

Good observation. So maybe this needs to go into a style-guide?

> 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

Well, it's arguable, I mean that CPU load is going to be fairly
keyboard-bound, and people can't type so far it'd make a major impact.
Every bit counts, though, and I like to write tight code when there is no
reason not to, and in this case I think the end-result is also cleaner to
some standards (It just doesn't conform to single form). I did consider
the array-alternative, mostly because that would've been the easiest way
to match the responses with Sun's implementation, but the table would've
taken prohibitively lot of space, even if you'd actually use all bits of
the array. Maybe for the first 256 codes it might be manageable.

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

Whole Java integer-type is legal range for the keycode, in essence, but I
think the highest one that's supposed to be a action-key is somewhere in
the 15-bit range.

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

Yeah, but the exception in Sun comes from another class, which is why I
didn't put it in this patch.

> good to hear that xsmiles works with kaffe!

Well, it worked quite fine back there, too, but since both Kaffe and
X-Smiles keep getting changed, they eventually stop working at some point.
During my summer vacation at least the Swing/KeyEvent part and HTTP file
requests broke (patch to both submitted). This obiviously makes trying to
match the Kaffe/X-Smiles releases rather hard, I have no idea right now if
the latest X-Smiles release works with the latest Kaffe release for
example. In theory it does.

However, we're going to release a new version RSN, and that won't work
without the submitted patches to Kaffe. Altough we might be persuaded to
try to implement some sort of work-arounds in X-Smiles to get them to work
- though I'm working part-time now, and just keeping the HEAD revisions
working together is enough work not to have to worry about backwards
compatibility ;) I'll ask around if it's something we want to do, though,
but I'd suggest Kaffe try to live up to the "Release early, release often"
model.

 -Jukka Santala