status of gcj

Wed Sep 17 04:36:00 GMT 2008

Please keep java@gcc.gnu.org CCed.
Johannes Klarenbeek wrote:
> 2008年9月15日 David Daney <ddaney@avtrex.com>:
>>> Johannes Klarenbeek wrote:
>>>>> hi there,
>>>>>> i looked at the excellent gcj project, but was a little confused about
>>> the status of the project. for example...
>>>>>> last gcj news flash is at march 30, 2007
>>> last cni update is october 22, 2000
>>> last classpath update is june 6 of 2008
>>>>>>>> The GCJ News is not keep very current. But there is still work being done
>> on GCJ and libgcj.
>>>> what parts are not very current at the very moment concerning the byte
> code implementation of java in gcj?
>
I was talking about the web site. I'm not sure what your question was 
though.
> i was reading about the gnu compiler collection on wikipedia and
> found that the gnu compiler is separeted in two parts (3 really); a
> front-end and a back-end. the front-end parses languages like C, C++,
> java, ADA, fortran and more. the back-end should support multiple
> processor architectures. i guess that gcj is the front-end part in gcc
> isnÂ´t it?
>>
Correct.
>>> where is project going too? how is the libgcj doing... is it already
>>> obsolete and replaced by classpath?
>>>>>>>> For the last several years libgcj has been based on classpath. So it is not
>> being replaced by classpath, for the most part it *is* classpath adapted to
>> work with gcj.
>>>> is libgcj a library that implements VMObject, VMString and some calls
> for AWT for example? so classpath can call the methods on these native
> objects whereas libgcj calls methods on the operating system to draw a
> windows for example?? if that is true, does libgcj support besides
> xlib also win32?
>>
That is the basic idea, but the specifics are slightly different. For 
the case of Object, String, Class, and several other classes in the 
java.lang package, libgcj completely replaces the classpath 
implementation. For some of the I/O classes libgcj does implement the 
VM* interfaces. The majority of the code in classpath does not have VM 
dependencies, so the gcj specific parts of libgcj are a small percentage 
of the total code.
David Daney