Interrupted IO and AWT
Mon Mar 20 08:21:00 GMT 2000
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
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.
More information about the Java