Interrupted IO and AWT
Jeff Sturm
jsturm@sigma6.com
Mon Mar 20 12:42:00 GMT 2000
Per Bothner wrote:
> The two approaches have different trade-offs:
> - Native peers can probably be implemented faster than a Swing-like
> solution.
To my knowledge there exist no free or third-party implementations of
Swing. It could be extremely difficult to do.
> - Native peers may have better compatibility (both look-and-feel and
> programming-wise) than pure Java widgets.
Especially if a toolkit (i.e. GTK+) is used. It's also possible to
write native peers using Xlib or Win32/GDI directly... though this leads
to the same interoperability problems as Swing.
(Sun never really got this part right. AWT applications on Linux don't
look right because Sun used the archaic Motif toolkit. Early versions
of the Win32 JDK did use MFC to inherit a certain amount of Win32
behavior, but that was later scrapped for direct window/graphics calls.)
> - Pure Java widgets allow compatibility with Swing's "pluggable-
> look-and-feel" (PLAF). However, I'm not sure that is important.
> I would rather have PLAF built using (say) gtk's theability.
Me too.
Let's say somebody wants to use gcj to write desktop apps for KDE or
Gnome. How would they best proceed? Swing is not a good fit because
apps written in Swing tend to look like, umm, Swing. The PLAF's are a
bad idea because they don't leverage a native toolkit, they attempt to
reimplement it in Java. Consequently Swing PLAFs are both difficult to
write and imperfect in their emulation.
AWT isn't so good either because it doesn't leverage much of the
capability of good toolkits out there... e.g. there is no tree widget or
image button in AWT.
I'd like to see real Java bindings in GTK and/or KDE so developers can
write first class Java apps for those environments. Then implement AWT
and (possibly) Swing atop this native API to be compatibile with other
Java applications.
To me this is consistent with the apparent philosophy of the gcj
project: remain compatible with Java but innovate where appropriate.
Gcj has already innovated with CNI.
(Those who are in the "pure Java" camp will likely disagree with me. My
aim is not to compromise Java compatibility, but extend its reach to
application domains where it has flopped, like desktop programming.)
--
Jeff Sturm
jsturm@sigma6.com
More information about the Java
mailing list