
The Deletion of gcj - mynameislegion
http://tromey.com/blog/?p=911
======
rekado
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.

Bootstrapping becomes harder and more legacy software needs to be accumulated
in order to actually build new software from source.

(I'm working on GNU Guix, a functional package manager, and I wrote the
package definitions for the JDKs.)

~~~
josteink
As someone who worked on porting Microsoft .NET Core to new platforms, that's
definitely a pain I felt.

At first, very few assumptions was made about the Unix bootstrapping process,
and the mantra was that you should build the managed components on a Windows
machine which already had .NET.

Just to get _something_ going, the Unix community decided to use mono to
bootstrap the process on non-Windows platforms. This effectively meant you
could bootstrap .NET Core on almost any platform where mono was around. That
gave quite some platform reach out of the box, and on overall an improvement
much welcomed by Microsoft.

But later, after Unixes like Linux and OSX become better supported, the
bootstrapping method changed to downloading a _previous_ build of .NET Core
for the current platform and using that to build the latest sources. I.e.
going self-bootstrapping, which sounds fancy on paper.

The cost of that? Suddenly it just wasn't doable (without considerable
knowledge and effort) to bootstrap .NET Core from source any more on platforms
not currently considered first class.

I'm not just talking about "strange" outlier OSes like FreeBSD, NetBSD or
Alpine Linux or whatever. Just trying to build for Fedora 24 (which doesn't
have published packages) fails. This is because the Fedora 23 packages are
linked against library-versions which are no longer in Fedora 24.

You'd think that be easy to fix, but now, even with Fedora 25 betas starting
to ship, there's _still_ no official Fedora 24 package exists from Microsoft,
so Fedora users (and developers, and porters, etc) are SOL.

So now basically just trying to bootstrap for a previously supported
mainstream Linux-distro is seriously PITA, next to impossible. In my honest
opinion that's a _major_ regression just for the sake of being self-
bootstrapping.

So yeah. You should never underestimate the value of having secondary
platforms available for bootstrapping your own. You may come to depend on it.

~~~
lmm
> I'm not just talking about "strange" outlier OSes like FreeBSD, NetBSD or
> Alpine Linux or whatever. Just trying to build for Fedora 24 (which doesn't
> have published packages) fails. This is because the Fedora 23 packages are
> linked against library-versions which are no longer in Fedora 24.

This sounds like more of an issue with Fedora than anything else. If Fedora 24
can't run programs for Fedora 23 (not ancient programs that happened to work
on Fedora 23, but programs that were specifically built for Fedora 23), that's
pretty ridiculous.

~~~
snuxoll
Fedora maintains binary compatibility within a specific release, but major
versions of software are updated every 6 months and if the ABI is different a
soname bump will happen. Unless software in the Fedora repositories flat out
will not build or run with a newer ABI-release of a dependency older versions
of the library aren't typically packaged.

In all honesty it's virtually never an issue, most libraries maintain _API_
compatibility and everything gets a mass-rebuild before alphas start to ship
(though everyone tries to notify affected maintainers when they are going to
do a soname bump on the mailing list) - so as long as you don't depend on old
libraries for _bootstrap_ of new package versions it's fine. There's plenty of
compilers in the repositories that bootstrap themselves every release without
giving grief, so Microsoft needs to either provide an external bootstrap
mechanism again or reduce the dependencies needed to get it bootstrapped to
preferably nothing more than glibc.

------
lsd5you
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.

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.

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.

[1] That is this one, there are several now doing similar things (!).
[http://www.xwt.org/](http://www.xwt.org/)

The code lives on here
[https://sourceforge.net/projects/vexi/](https://sourceforge.net/projects/vexi/)

~~~
correktlogic
Anyone know if gcj ever experimented with a precise GC? Or did the design of
GCC simply not allow for a non-conservative GC implementation?

~~~
gumby
Historical. We implemented the Bohm GC at Cygnus, funded by Metaphor back
around 92/93 if I remember. GCC is / was very conservative.

------
dragonquest
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.

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.

~~~
TheCondor
I live in the moment! Enjoy and cherish those magical times when the work is
right, the team is right, and you're having fun. Don't let the stupid stuff
bother you.

You can rebuild teams like that, find those projects, etc.. but it feels like
an eternity when you've had it and then don't have it for a while.

------
aardvark179
[http://openjdk.java.net/jeps/8166089](http://openjdk.java.net/jeps/8166089)

One Java AOT option goes away, and a new one is arriving.

~~~
iso-8859-1
Hopefully the new one can replace RoboVM as well...

~~~
chrisseaton
I'm afraid the job of the new AOT is not to produce standalone binaries - it's
code to be loaded into the JVM, not to run without it.

------
okket
GCJ was deemed obsolete in 2010, amazing that it was still around until now...

[http://stackoverflow.com/questions/3032727/java-jre-vs-
gcj](http://stackoverflow.com/questions/3032727/java-jre-vs-gcj)

Did anyone used GCJ for something in production?

~~~
marktangotango
I evaluated gcj to use in a shareware desktop application in the 2000's. The
goal was to compile java + SWT into native binaries for distribution. The goal
was a slim installer that didn't require the user to futz with installing
java, or bunding a jre. Ended up going with Excelsior JET which is a fantastic
project.

In the end, the full java spec doesn't lend itself to aot, because if you
claim to be "real" java you have to include support for runtime classloading,
which means there has to be a bytecode interpreter embedded in there
somewhere. My thoughts are now, if you really want a java/c# style aot
language, vala is the way forward.

~~~
my123
C# fully supports AOT since a while.

~~~
swift
I'm pretty sure that C# AOT does not eliminate the need for a JIT in the
runtime system. Just as one example, how could expression trees be implemented
without one?

~~~
pjmlp
You cannot use them.

In .NET Native you have to explicitly inform the compiler of any kind of
reflection behavior you might require.

~~~
zgramana
Not quite right. Mono has the lovely mkbundle tool which can do what the
poster wants: AOT your intermediate/byte code and build a statically linked
executable containing your app, the runtime, and all your deps (except for key
system dynamic libraries like libc or Security.framework, similar to how go
works).

No restrictions on reflection, unlike .NET Native (which has slightly
different design goals).

I've used it many times for just this reason with great results. Plus, the
runtime was re-licensed to MIT/X11.

~~~
pjmlp
My .NET experience is only on Windows, thanks for the clarification.

------
correktlogic
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.

[https://gcc.gnu.org/onlinedocs/gcj/About-CNI.html#About-
CNI](https://gcc.gnu.org/onlinedocs/gcj/About-CNI.html#About-CNI)

------
wodencafe
It seems the most beloved feature of GCJ was its ability to compile Java to
native code.

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.

The performance improvements could be taken even further by something like
this, Java to native code compilation.

------
myhf
Google cache:
[http://webcache.googleusercontent.com/search?q=cache:zFK8UNR...](http://webcache.googleusercontent.com/search?q=cache:zFK8UNRnBpkJ:tromey.com/blog/%3Fp%3D911)

------
akx
gcj being killed means someone needs to reimplement pdftk in... well,
something else. D:

~~~
LukeShu
Indeed, that was my concern as well.

The best solution is probably to replace the C++ bits with Java, and go full
JVM.

~~~
akx
Yep. I recently had to get pdftk running on an old Centos-or-whatever system,
and that ended up being a big fat no-go, so I reimplemented the functionality
we needed from pdftk (filling forms) with just Java:
[https://github.com/akx/foofdf](https://github.com/akx/foofdf)

------
pritambarhate
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?

------
fake-name
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?

~~~
tombert
Yeah, I mean, it's just incredibly hard to go on Wikipedia and look up "gcj".
All I got was this extremely informative page about an open source java
compiler:
[https://en.wikipedia.org/wiki/GNU_Compiler_for_Java](https://en.wikipedia.org/wiki/GNU_Compiler_for_Java).

