Interrupted IO and AWT

[Tom Tromey]

Jeff> If I had my choice, interruptable I/O would be a configure-time
Jeff> option that could be turned off for strict JDK compatibility (or
Jeff> better performance/robustness in the case of Win32).

I think this would be a reasonable approach.

>> Secondly, I'm quite interested in doing some work on implementing
>> AWT (I'm more intrested in Client stuff myself). I was wondering if
>> someone could clear up the position of this, esp. regarding the
>> Classpath merger. I seem to recall that everything from Classpath
>> is available except the AWT code.  Now is this all AWT code or just
>> the native implementation? IF I do use it what is the final result?
>> That the executable is cover by the GPL? I can live with that for
>> now...

Jeff> From looking at Warren Levy's latest patches, I'd guess that the
Jeff> libgcj maintainers haven't given up on doing their own AWT port,
Jeff> independently of classpath.

Warren's recent patches notwithstanding, we haven't started
implementing AWT.  Those were needed for something else.

Jeff> AWT would be great... you might consider a portable toolkit
Jeff> (GTK?)  though before it becomes too Win32-centric, so that
Jeff> other platforms can benefit.

My goal is to have a retargetable AWT -- one where we can plug in
different back ends.  So we might have a Gtk+ back end (the one I'd
like to see :-), a Windows back end, and even a back end running on a
framebuffer (for embedded folks).  I don't know enough about AWT to
say whether this is a realistic plan.

Tom