classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Event class?


From: Shane Nay
Subject: Re: Event class?
Date: Fri, 11 May 2001 02:17:38 -0700

> 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.

I don't see any reference within the libgcj site about an interprettor driven 
enviro that can utilize libgcj?  Does such a thing exist?  (Or is it simply 
possible?)  See, my background, and primary interest is in embedded stuff (I 
used to work for AgendaComputing BTW), these types of enviroments would 
benefit greatly from an interpretter driven setup.  So you don't *need* the 
cross compiler, this confuses lots of would be developers.  They would also 
be greatly benefitted by native code with efficient link ups between the 
interpretted code and the native code (i.e. native calling conventions, pass 
args through registers, etc.)  But having a compiler such as gcj on board is 
a no go because of the space and resource limitations inherent in cost 
effective embedded devices.  So, what I would really like is to either have a 
fully interpretted enviro such as GNUClasspath and some VM, or some 
conglomeration of libgcj that allowed a VM.

> 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).

Right, but the xlib is much more developed.  And re-implementing the Xlib 
peer architecture for a widget based architecture is substantially more 
complex than implementing a new widget based architecture based on a prior 
widget based implementation.  (For instance, I re-wrote all the java calls in 
gnu.java.awt.gtk in a matter of 10 hours or so for pgui, re-aligning the 
inheritances where it made since in the other enviroment.  If I were to do 
this for a more low level drawing peer driven architecture like Xlib it would 
have to be basically re-designed in order for it to be coherent)

> 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".

Maybe :).  There is some argument with respect to whether it should "inherit" 
the license from GNUClasspath, or gtk itself.  I could really care less, 
LGPL, or GPL with exception is fine for me either way.

Thanks,
Shane Nay.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]