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

[Dalibor Topic]

Hi Jukka,

--- Jukka Santala <jsantala at morphine.tml.hut.fi>
wrote:
> 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

I believe that's in part due to too much debugging
information being generated by kjc. Could you try
compiling the class library with javac and jikes and
compare the resulting rt.jar sizes?
 
> > 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.
 
Different application will need different profiles.
Encoding profile information in comments is a bad
idea, in my opinion, as it leads to a lot of
uninformative comments. I'd prefer to see an external
file, like the bootstrap classes file we use currently
to denote all the classes needed to be present to
compile kaffe's rt.jar successfully.

> > 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'd propose 10 files:
applet.jar,
awt.jar,
beans.jar,
net.jar,
math.jar,
sql.jar,
text.jar,
i18n.jar (for locale, timezone, and character
converter data),
security-apis.jar (for java.security.*.* classes),
rt.jar (for the rest/i.e. core).

additional benefit of having a couple of small jar
files would be decreased memory requirements to build
kaffe. Currently it takes more than 32 mb to compile
rt.jar using kjc on i386-linux.

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

O.K. Post a FAQ entry on inlining for the codestyle
FAQ, and I'll check it in when I'm back from .ma ;)

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

> 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 values for VK_* range from 0x00 to 0xFF in the
current kaffe implementation (jdk 1.1) did that change
in JDK 1.4? I assume that VK_* represent all keyCodes
one can have in a Java application, did I get that
wrong? If the range is only 256 values, then we shoudl
use an array, in my opinion.

> > good to hear that xsmiles works with kaffe! 
> 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

please don't work around kaffe's bugs in your code.
Submit patches. That fixes it for everyone.

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

Agreed. Blame everyone's limited personal resources
and all that. I guess it would be easier for Jim if we
had an automated regression tesing setup, but at the
moment there is only the flest mails (thanks to
JanosVM developers).

cheers,

dalibor topic

p.s. this mail intentionally kept short, as yahoo ate
my previous, longer attempt at it. Mailbox in invalid
state and all that. Internet cafes with slow
connections can be such a joy sometimes.

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com