Re: status of gcj

2008/9/17 David Daney <[email protected]>:
> Johannes Klarenbeek wrote:
>>
>> 2008/9/16 David Daney <[email protected]>:
>>>
>>> Please keep [email protected] CCed.
>>>
>>> Johannes Klarenbeek wrote:
>>>>
>>>> 2008/9/15 David Daney <[email protected]>:
>>>>
>>>>> 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