This is a little sad because this means we will have to keep around old versions of GCC with GCJ in order to be able to bootstrap the JDK from source (without a binary bootstrap JDK). Only OpenJDK6 (with the extensive IcedTea patches) can be bootstrapped with GCJ alone, so we also have to keep OpenJDK6 around in order to be able to build the latest JDK.<p>Bootstrapping becomes harder and more legacy software needs to be accumulated in order to actually build new software from source.<p>(I'm working on GNU Guix, a functional package manager, and I wrote the package definitions for the JDKs.)
It was used for creating the native builds of XWT [1] 15 years ago. At the time I found it amazing to see Java programs becoming native (a lot snappier and generally faster too). It seemed (naively) to be beyond what was possible.<p>However, the main problem with GCJ was it used conservative garbage collection - boehm GC - and as such was fundamentally broken for long running programs (what java is good for). Without wanting to denigrate it too much, it seems to me that a lot of 'good' work has been put into this approach which was essentially a cul-de-sac.<p>I had a related rather general thought recently about documenting features in projects. Sometimes the hardest thing to know is whether something is in fact a good idea or not (both in theory and in practice) and the amount of effort/quality of documentation is probably not a good indicator of this. So in the case of the GCJ garbage collector, there was always a lot of talk about how clever the garbage collector was and all the technical aspects, but unless you were already an expert, how would you know if it was infact a good idea or not.<p>[1] That is this one, there are several now doing similar things (!).
<a href="http://www.xwt.org/" rel="nofollow">http://www.xwt.org/</a><p>The code lives on here
<a href="https://sourceforge.net/projects/vexi/" rel="nofollow">https://sourceforge.net/projects/vexi/</a>
This is why you should always create something, even if you think it will never be accepted by a large audience. It is worth it for the journey itself.<p>Reading this post made me wish I had spent more time with 'gcj'. Though in all honesty I know I gave up on it because I didn't want to go the tougher way - the the normal JDK was just there. Creation is beautiful, and its ending bittersweet for the creator and the witnesses.
<a href="http://openjdk.java.net/jeps/8166089" rel="nofollow">http://openjdk.java.net/jeps/8166089</a><p>One Java AOT option goes away, and a new one is arriving.
GCJ was deemed obsolete in 2010, amazing that it was still around until now...<p><a href="http://stackoverflow.com/questions/3032727/java-jre-vs-gcj" rel="nofollow">http://stackoverflow.com/questions/3032727/java-jre-vs-gcj</a><p>Did anyone used GCJ for something in production?
What a shame about gcj being dropped. I remember using GCJ with CNI to interface with native C++ code was a much more pleasant experience than using JNI.<p><a href="https://gcc.gnu.org/onlinedocs/gcj/About-CNI.html#About-CNI" rel="nofollow">https://gcc.gnu.org/onlinedocs/gcj/About-CNI.html#About-CNI</a>
It seems the most beloved feature of GCJ was its ability to compile Java to native code.<p>Is this something that could be implemented in the Java JDK / OpenJDK? Understandably a lot of work, but Oracle is looking at AOT now, for performance reasons.<p>The performance improvements could be taken even further by something like this, Java to native code compilation.
Google cache: <a href="http://webcache.googleusercontent.com/search?q=cache:zFK8UNRnBpkJ:tromey.com/blog/%3Fp%3D911" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:zFK8UNR...</a>
Not directly related to topic, has anybody used Excelsior JET to compile Java apps to native code? How was your experience? Did it improve the start up time of the app? Did you find it any faster than using a JVM?
I skimmed the article, and all the comments here, and I still have no fucking idea what "gcj" is. It's apparently related to java. Maybe at least define your acronym once?