Question of the status of GCJ

Question of the status of GCJ

[Mike Purdy]

I would like to ask an admittedly embarrassing question regarding the
status of GCJ development and its use to natively compile SWT
applications for Linux, OSX, and perhaps Windows (though this is not an
immediate need).

The embarrassing part is that I've lost track for a while now of where
GCJ development is at, what version of java it supports, how it relates
to Sun's open sourcing of java, and what the future development plans
are for GCJ.  I would like to pick back up soon with the possibility of
natively compiling a couple projects, but I need to get back up to speed
with GCJ as a whole first.

I appreciate any insight anyone can provide.  Is natively compiling SWT
applications still supported or feasible?

Mike

Re: Question of the status of GCJ

[Andrew Haley]

Mike Purdy wrote:
> I would like to ask an admittedly embarrassing question regarding the
> status of GCJ development and its use to natively compile SWT
> applications for Linux, OSX, and perhaps Windows (though this is not an
> immediate need).
> 
> The embarrassing part is that I've lost track for a while now of where
> GCJ development is at, what version of java it supports, how it relates
> to Sun's open sourcing of java, and what the future development plans
> are for GCJ.  I would like to pick back up soon with the possibility of
> natively compiling a couple projects, but I need to get back up to speed
> with GCJ as a whole first.
> 
> I appreciate any insight anyone can provide.  Is natively compiling SWT
> applications still supported or feasible?

This comes up from time to time.

gcj is still there, and still works.  However, it has never been tested
for compatibility with Java, and I'm sure if it were so tested, it would
fail.  OpenJDK, as well as being a high-performance VM, is compatible with
Java, and so is more useful to many people.

So, most of the effort in the free software world now goes into OpenJDK.
However, people still use gcj.

The current gcj supports something vaguely like Java 1.5, but it isn't
complete AFAIAA.

Andrew.

Re: Question of the status of GCJ

[Mike Purdy]

Thank you Andrew.  

This is interesting.  Does the OpenJDK allow native compilation?

Mike

>>> Andrew Haley <aph@redhat.com> 2/17/2009 12:46 PM >>>
Mike Purdy wrote:
> I would like to ask an admittedly embarrassing question regarding
the
> status of GCJ development and its use to natively compile SWT
> applications for Linux, OSX, and perhaps Windows (though this is not
an
> immediate need).
> 
> The embarrassing part is that I've lost track for a while now of
where
> GCJ development is at, what version of java it supports, how it
relates
> to Sun's open sourcing of java, and what the future development
plans
> are for GCJ.  I would like to pick back up soon with the possibility
of
> natively compiling a couple projects, but I need to get back up to
speed
> with GCJ as a whole first.
> 
> I appreciate any insight anyone can provide.  Is natively compiling
SWT
> applications still supported or feasible?

This comes up from time to time.

gcj is still there, and still works.  However, it has never been
tested
for compatibility with Java, and I'm sure if it were so tested, it
would
fail.  OpenJDK, as well as being a high-performance VM, is compatible
with
Java, and so is more useful to many people.

So, most of the effort in the free software world now goes into
OpenJDK.
However, people still use gcj.

The current gcj supports something vaguely like Java 1.5, but it isn't
complete AFAIAA.

Andrew.

--- Scanned by M+ Guardian Messaging Firewall ---

Re: Question of the status of GCJ

[Andrew Haley]

Mike Purdy wrote:
> Thank you Andrew.  
> 
> This is interesting.  Does the OpenJDK allow native compilation?

No.

Andrew.

Re: Question of the status of GCJ

[Marco Trudel]

Andrew Haley wrote:
> Mike Purdy wrote:
>> Thank you Andrew.  
>>
>> This is interesting.  Does the OpenJDK allow native compilation?
> 
> No.

But it would be possible with (relatively) less work. I have written a 
Java source code to Eiffel source code compiler using the OpenJDK 
classes for the standard library. I have mapped all Java language 
constructs and implemented the runtime far enough so that simple SWT 
applications can be compiled (kind of "proof of concept").
There is a good chance that I can find someone continuing the work on it 
the next half year. I'm hoping that it will then be usable with real 
applications and also for Linux/Mac.
If you're interested, the website is http://jaftec.origo.ethz.ch/


Marco

Re: Question of the status of GCJ

[Andrew Haley]

Marco Trudel wrote:
> Andrew Haley wrote:
>> Mike Purdy wrote:
>>> Thank you Andrew. 
>>> This is interesting.  Does the OpenJDK allow native compilation?
>>
>> No.
> 
> But it would be possible with (relatively) less work.

Relative to writing the whole thing again, maybe, but still hard.

I'd love to find an excuse to do it.  gcj is still a very high-
performance implementation of the Java language.

Andrew.

Re: Question of the status of GCJ

[Marco Trudel]

Andrew Haley wrote:
> Marco Trudel wrote:
>> Andrew Haley wrote:
>>> Mike Purdy wrote:
>>>> Thank you Andrew. 
>>>> This is interesting.  Does the OpenJDK allow native compilation?
>>> No.
>> But it would be possible with (relatively) less work.
> 
> Relative to writing the whole thing again, maybe, but still hard.

Actually, I was talking about finishing JENC, not reimplementing GCJ. 
Reimplementing GCJ would probably be much harder.
By the way, I forgot to mention that a Java source code to Eiffel source 
code compiler automatically supports native compilation since Eiffel 
compiles to native by default (otherwise my whole mail would have been 
pointless)...


Marco

> I'd love to find an excuse to do it.  gcj is still a very high-
> performance implementation of the Java language.
> 
> Andrew.

Re: Question of the status of GCJ

[Dalibor Topic]

Marco Trudel wrote:
> Andrew Haley wrote:
>> Mike Purdy wrote:
>>> Thank you Andrew. 
>>> This is interesting.  Does the OpenJDK allow native compilation?
>>
>> No.
>
> But it would be possible with (relatively) less work. I have written a 
> Java source code to Eiffel source code compiler using the OpenJDK 
> classes for the standard library. I have mapped all Java language 
> constructs and implemented the runtime far enough so that simple SWT 
> applications can be compiled (kind of "proof of concept").
> There is a good chance that I can find someone continuing the work on 
> it the next half year. I'm hoping that it will then be usable with 
> real applications and also for Linux/Mac.
> If you're interested, the website is http://jaftec.origo.ethz.ch/
>
Thanks, Marco, that's an interesting use of the OpenJDK class library.

cheers,
dalibor topic

Re: Question of the status of GCJ

[Marco Trudel]

Dalibor Topic wrote:
> Marco Trudel wrote:
>> Andrew Haley wrote:
>>> Mike Purdy wrote:
>>>> Thank you Andrew. This is interesting.  Does the OpenJDK allow 
>>>> native compilation?
>>>
>>> No.
>>
>> But it would be possible with (relatively) less work. I have written a 
>> Java source code to Eiffel source code compiler using the OpenJDK 
>> classes for the standard library. I have mapped all Java language 
>> constructs and implemented the runtime far enough so that simple SWT 
>> applications can be compiled (kind of "proof of concept").
>> There is a good chance that I can find someone continuing the work on 
>> it the next half year. I'm hoping that it will then be usable with 
>> real applications and also for Linux/Mac.
>> If you're interested, the website is http://jaftec.origo.ethz.ch/
>>
> Thanks, Marco, that's an interesting use of the OpenJDK class library.

For those who are interested in the JENC internals, here some points 
that considerably facilitated the work I had to do (points where GCJ 
needs substantial additional effort):
- I don't need to replace any OpenJDK classes with own implementations. 
All classes (String, AWT/Swing, nio, xml, ...) can be taken directly 
from OpenJDK. So there's no danger of bringing additional bugs in and 
the quality of OpenJDK can be reused.
- The same applies for the native libraries. All except jvm.dll can be 
reused without modification (even java.dll). jvm.dll has to be 
reimplemented because it's specific to the Sun (OpenJDK) JVM. A built-in 
JNI implementation allows this reuse of the libraries.
- Since the Java classes are simply transliterated to Eiffel and Eiffel 
is also a high level programming language, stuff like exceptions and a 
garbage collector come naturally.


So, if GCJ will be redone for OpenJDK (what would be great because 
there's a big community), I hope they could also choose a similar 
approach for not needing an own implementation of classes (and therefore 
also keep the OpenJDK native libraries).


have a nice day
Marco

> cheers,
> dalibor topic

Re: Question of the status of GCJ

[Mark Wielaard]

Hi Mike,

On Tue, 2009-02-17 at 09:45 -0500, Mike Purdy wrote:
> I would like to ask an admittedly embarrassing question regarding the
> status of GCJ development and its use to natively compile SWT
> applications for Linux, OSX, and perhaps Windows (though this is not an
> immediate need).

I don't have experience with OSX and Windows, but for GNU/Linux this has
been certainly possible for a couple of years already. Others did do
such things for other platforms.

> The embarrassing part is that I've lost track for a while now of where
> GCJ development is at, what version of java it supports, how it relates
> to Sun's open sourcing of java, and what the future development plans
> are for GCJ.  I would like to pick back up soon with the possibility of
> natively compiling a couple projects, but I need to get back up to speed
> with GCJ as a whole first.

The compiler accepts any modern java language feature, the class
libraries are somewhere between 1.5 and 1.6 depending on package. There
are currently no concrete plans to augment the classes with some of
Sun's new GPLed code. But there has already been a patch to make use of
the OpenJDK javac compiler directly (but that hasn't been integrated
yet).

> I appreciate any insight anyone can provide.  Is natively compiling SWT
> applications still supported or feasible?

Certainly, this has been possible for a long time now (a quick search
reveals that people have been doing that since 2003). It would be a
regression if that breaks. In fact the whole eclipse suite can be
compiled and run with gcj. 

Cheers,

Mark

Re: Question of the status of GCJ

[Bryce McKinlay]

On Tue, Feb 17, 2009 at 7:36 PM, Andrew Haley <aph@redhat.com> wrote:
>
> Marco Trudel wrote:
> > Andrew Haley wrote:
> >> Mike Purdy wrote:
> >>> Thank you Andrew.
> >>> This is interesting.  Does the OpenJDK allow native compilation?
> >>
> >> No.
> >
> > But it would be possible with (relatively) less work.
>
> Relative to writing the whole thing again, maybe, but still hard.
>
> I'd love to find an excuse to do it.  gcj is still a very high-
> performance implementation of the Java language.

Such a merge could proceed gradually, along similar lines to the
original Classpath-GCJ merge. It would be a lot of work to merge all
the way down to java.lang, but higher level packages, such as
AWT/Swing, should be able to plug in relatively painlessly and provide
a lot of benefit.

I guess the major stumbling block is persuading the FSF and/or
Steering committee to allow the OpenJDK code in the GCC repository -
otherwise this work would have to proceed in a forked tree.

Bryce

Re: Question of the status of GCJ

[Andrew Haley]

Bryce McKinlay wrote:
> On Tue, Feb 17, 2009 at 7:36 PM, Andrew Haley <aph@redhat.com> wrote:
>> Marco Trudel wrote:
>>> Andrew Haley wrote:
>>>> Mike Purdy wrote:
>>>>> Thank you Andrew.
>>>>> This is interesting.  Does the OpenJDK allow native compilation?
>>>> No.
>>> But it would be possible with (relatively) less work.
>> Relative to writing the whole thing again, maybe, but still hard.
>>
>> I'd love to find an excuse to do it.  gcj is still a very high-
>> performance implementation of the Java language.
> 
> Such a merge could proceed gradually, along similar lines to the
> original Classpath-GCJ merge. It would be a lot of work to merge all
> the way down to java.lang, but higher level packages, such as
> AWT/Swing, should be able to plug in relatively painlessly and provide
> a lot of benefit.

That's true.  I guess my problem is that I'm not very interested in all
that AWT/Swing stuff.  :-)

> I guess the major stumbling block is persuading the FSF and/or
> Steering committee to allow the OpenJDK code in the GCC repository -
> otherwise this work would have to proceed in a forked tree.

I don't think that there is any need at all for the OpenJDK code to
be checked in to the GCC repository.  glibc is happily outside the
GCC repo, after all.  All the work could be done in the IcedTea
repository.

Andrew.

Re: Question of the status of GCJ

[Mark Wielaard]

On Wed, 2009-02-18 at 10:16 +0000, Andrew Haley wrote:
> Bryce McKinlay wrote:
> > On Tue, Feb 17, 2009 at 7:36 PM, Andrew Haley <aph@redhat.com> wrote:
> >> I'd love to find an excuse to do it.  gcj is still a very high-
> >> performance implementation of the Java language.
> > 
> > Such a merge could proceed gradually, along similar lines to the
> > original Classpath-GCJ merge. It would be a lot of work to merge all
> > the way down to java.lang, but higher level packages, such as
> > AWT/Swing, should be able to plug in relatively painlessly and provide
> > a lot of benefit.
> 
> That's true.  I guess my problem is that I'm not very interested in all
> that AWT/Swing stuff.  :-)
> 
> > I guess the major stumbling block is persuading the FSF and/or
> > Steering committee to allow the OpenJDK code in the GCC repository -
> > otherwise this work would have to proceed in a forked tree.
> 
> I don't think that there is any need at all for the OpenJDK code to
> be checked in to the GCC repository.  glibc is happily outside the
> GCC repo, after all.  All the work could be done in the IcedTea
> repository.

To combine those two remarks. One idea might be to follow the JigSaw [1]
proposal and have the same "core" module as OpenJDK with its own
lang/io/net/security/util/etc stuff for libgcj inside the GCC tree. And
then have all "higher-level" modules separately (but hopefully still
pre-compiled). That of course depends on the details of the JigSaw
proposal, but it seems an attractive route to investigate if you want
"additional libraries" outside the GCC repo and a way to gradually move
towards alternative core libraries on top of (lib)gcj.

Cheers,

Mark

[1] http://blogs.sun.com/mr/entry/jigsaw

Re: Question of the status of GCJ

[Mike Purdy]

Thank you all for your information.  

So, if I understand the summary of this.. although effort has shifted
to OpenJDK, gcj is still viable and potentially a good performing
solution if our code is generally 1.5 code.  Further, current gcj
native-compile functionality will not break in the future, so a project
built with gcj in its build stream will be ok for a while to come. (?)

Mike



>>> Mark Wielaard <mark@klomp.org> 2/18/2009 4:05 AM >>>
Hi Mike,

On Tue, 2009-02-17 at 09:45 -0500, Mike Purdy wrote:
> I would like to ask an admittedly embarrassing question regarding
the
> status of GCJ development and its use to natively compile SWT
> applications for Linux, OSX, and perhaps Windows (though this is not
an
> immediate need).

I don't have experience with OSX and Windows, but for GNU/Linux this
has
been certainly possible for a couple of years already. Others did do
such things for other platforms.

> The embarrassing part is that I've lost track for a while now of
where
> GCJ development is at, what version of java it supports, how it
relates
> to Sun's open sourcing of java, and what the future development
plans
> are for GCJ.  I would like to pick back up soon with the possibility
of
> natively compiling a couple projects, but I need to get back up to
speed
> with GCJ as a whole first.

The compiler accepts any modern java language feature, the class
libraries are somewhere between 1.5 and 1.6 depending on package.
There
are currently no concrete plans to augment the classes with some of
Sun's new GPLed code. But there has already been a patch to make use
of
the OpenJDK javac compiler directly (but that hasn't been integrated
yet).

> I appreciate any insight anyone can provide.  Is natively compiling
SWT
> applications still supported or feasible?

Certainly, this has been possible for a long time now (a quick search
reveals that people have been doing that since 2003). It would be a
regression if that breaks. In fact the whole eclipse suite can be
compiled and run with gcj. 

Cheers,

Mark


--- Scanned by M+ Guardian Messaging Firewall ---

Re: Question of the status of GCJ

[Andrew Haley]

Mike Purdy wrote:

> So, if I understand the summary of this.. although effort has shifted
> to OpenJDK, gcj is still viable and potentially a good performing
> solution if our code is generally 1.5 code.  Further, current gcj
> native-compile functionality will not break in the future, so a project
> built with gcj in its build stream will be ok for a while to come. (?)

I think so, but it all depends on whether people keep it maintained.
The only way you can guarantee future support is either to pay
someone to support it, or do so yourself.

Andrew.