>Providing a set of palmos classes to be used for GUI programming would
>encourage developers to write Java that ran only on PalmOS. It would
>be similar to what Microsoft did for Windoze -- and what Sun's suing
>them for.
>
>Admitedly, the trifurcation of the JDK into J2ME, JDK personal (or
>whatever) and "Enterprise Edition" is a small step away from "write
>once run anywhere." But I bet Sun's extremely wary of being seen
>taking any further steps in that direction.
This is unquestionably the case; it's a shame when considerations like this
result in "lowest-common-denominator" features. This is one thing which
helped make the original AWT such a failure. In the KVM's case, the fact
that the only thing you're supporting is points and lines makes it
effectively useless, which in some ways is worse than having it
platform-specific.
On the other hand, Swing for Palm ain't likely anytime soon ...
>An AWT (or JFC) based on PalmOS peers would make perfect sense in
>terms of Sun's (apparent) strategy. But it may not be possible to
>write something close to the AWT given the constraints of current Palm
>hardware. The JDK is pretty huge.
Very true; this is why Swing isn't available on J2ME. Swing requires
various packages like Java2D, which is quite large (large enough that, say,
the larger CE platforms can't accomodate it easily).
On the other hand, there's no reason why a partial AWT, or even an AWT-like
toolkit, couldn't be provided. The KVM core classes aren't that much like
the desktop core classes, for example; why not scale down the UI, too?
The closest thing to Swing they've done yet in the KVM (that is,
lightweight platform-independent components) is the text box component; I
forget what it's called. Personally, I don't think it's that workable. Much
too slow.
Regards,
Ben Flaumenhaft
