status of gcj

Wed Sep 17 17:37:00 GMT 2008

2008年9月17日 David Daney <ddaney@avtrex.com>:
> Johannes Klarenbeek wrote:
>>>> 2008年9月16日 David Daney <ddaney@avtrex.com>:
>>>>>> 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.
>>>> oh sorry. i was wondering if the compiler (and interpreter)
>> implementation is up to date with the current java sun implementation.
>> not referening to the Classpath implementation. for example: does gcj
>> implement generics (or what are they called ... templates like
>> c++?)... is the java byte code generation by gcj after source code
>> compilation equal to the latest java specs etc...
>>>>> The current (as of 4.3) version no longer generates byte code, nor directly
> compiles .java source files. Instead we use ecj (Eclipse Compiler for Java)
> to do the java->class compilation. GCJ then compiles the class files
> (bytecode) into native code. This give us full java generics support.

so that means to compile a java file from source i need to download
the eclipse compiler for java as a seperate download..
>>>>>> 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.
>>>> ok, how big is the gcj specific front-end part compared to for example
>> c++... did the developers copy a lot of code from the c++ project and
>> changed it to fit the java requirements?
>>>> GCJ was started many years ago. I don't know how much was borrowed from the
> C++ compiler, but currently it is completely separate. As for the size, I
> don't know a good unit to use to measure it.
>>> since the back-end of gcj produces java byte code as well, does that
>> mean one can write c++ programs and compile it to java byte code?
>>>>>>>> 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.
>>>> sorry, i lost you there... the gcj specific parts of libgcj are a
>> small percentage of the total code? what do you mean? leaving
>> Classpath out of the story, the code generated from source by gcj
>> links to libgcj isn´t it?
>> The entire java runtime library is quite large. For gcj the runtime library
> is called libgcj. The amount of gcj specific code in libgcj that differs
> from the classpath project is small compared to the total amount of
> classpath code used.
>> All code compiled by gcj must be linked to libgcj to be useful.

clear.
>>>>> another question, maybe a little off topic since its a classpath
>> related question. just out of curiousity, can a bsd licensed java
>> compiler use the classpath library?
>>> Read the classpath license.

ok,
thanks,
johannes