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

[Jukka Santala]

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

Hm, "Uninformative comments", what about JavaDoc? ;) At any rate, the
problem I was trying to communicate through is that you can't get away
with class-level division all of the time. As a case-in-point example, in
JDK 1.4 AppletContext got getStreamKeys() method... which returns an
Iterator.

Unfortunately, AppletContext is in JDK 1.1, but Iterator isn't.  If you
try to implement class-level division for what's included in a JDK 1.1
profile, you either have to leave that method off JDK 1.4 profile as well,
or include most of Collections Framework in JDK 1.1 profile. Besides of
which, classes implementing AppletContext will break if they don't
implement getStreamKeys().

There are a lot of similiar situations, but that's one I'm familiar with.
These problems are easily solved if we allow a way to signal that
getStreamKeys() method is to be left out of <1.4 builds. I agree that a
class-list would be in some ways "optimal" solution, but unfortunately it
isn't sufficient for most real-world situations.

> 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 don't see any major reasons to object to that plan, altough most of
those jar files would be very small, and thus little overall advantage. Do
we already have java.util as separate jar-file, or is it too widely
depended on? Another large overall package would be java.io, but I think
practically everything uses that. Breaking awt off into separate package
probably gives the largest effect. Overall I don't think there are many
applications where those separate packages are going to be overly useful.
Maybe some limited environments could do without sql/security/util.

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

VK_CUT is 0xFFD1. It should be noted that I doubt the >0xFF keys can
currently be actually generated by the VM/input layer. At some point they
should. Also, Java APIdoc says one should not rely on the values of the
VK_ constants, so it would be perfectly in keeping with the spec to remap
them all to 0xFF range. Overall I think keeping with Sun's is best. As
suggested, we could sue hybrid: If the value is 0xFF or less (most common
case), use array, otherwise check ranges. However, in overal analysis, I
think that function is called too rarely to warrant the speed-size
tradeoff. Altough if we use BitSet (dependency to java.util;), it's a
tough call. I think the present way is simplest and safest.

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

Yeah, I do, but since we're aiming at Kaffe compatibility, it's bit
awkward if the patches haven't been incorporated to the latest Kaffe
release. Since our roadmap (And Richard Stallman:) currently calls for a
Kaffe compatible release at the end of the month, this is bit tricky
without tighter Kaffe release schedule or work-arounds in XSmiles.

However, working around the KeyEvent bit for example is a pain, since we
can't fix Sun's Swing package, or easily debug what goes wrong. Getting
around Kaffe leaving LF off the last CR/LF pair of headers in HTTP stream
is trivial, but unfortunately this mod goes to Xalan/Xerces, and I'm
almost certain they wouldn't approve of that patch in their releases.
Which is why I'm asking for more frequent Kaffe releases.

 -Jukka Santala