>>>>> "Shane" == Shane Nay <[EMAIL PROTECTED]> writes:
Shane> However..., doing libgcj really limits what I can do, and I
Shane> don't really like that. (Unless libgcj.so can be mmap'd for a
Shane> "normal" VM?)
I don't know what you mean. On interpreter-enabled platforms using
libgcj should be just like using Sun's java interpreter. Unless of
course you are trying to use the JNI invocation API, which we still
haven't implemented. The interpreter works on x86, PPC, IA-64, and
alpha.
Shane> Also gcj's AWT is based around much lower level code than what
Shane> I'd like..., looks like Xlib calls, but I need to make it all
Shane> widget level stuff with Peers and the like.
This sounds like confusion on your part. libgcj's AWT, such as it is,
is based on a standard peer approach. There are partial
implementations of two different sets of peers: the raw xlib peers and
the Gtk peers (based on the Classpath peers).
Shane> What's everyones vibe on Classpath's AWT? Would you like to
Shane> see it fixed?, would a fixed AWT be accepted into the core of
Shane> GNUClasspath?
I'm sure the answers to both are "yes".
Tom
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
