library must lift one of the main barriers to writing portable code, though there are other approaches to this, i.e. porting GUI toolkits from one platform to another so that code that uses the toolkit will be portable.
The code generation for a virtual machine would obviously appeal to the writers of comercial software because it means they can distribute just one version of the software without having to give away the source code. What I don't see is how this is an advantage to free and open source software where the problem of distributing platform neutral code is usually solved by distributing the source.
I have not played with GJC yet so I can't commenet on that.
For me, the interesting thing about GCJ is the claim to be able to translate the java VM code into native code ahead of time and save the result (as an ordinary executable) rather than do it each time the program is run. I am not sure how much difference this would make but it does seem to me that there is a noticable speed penalty associated with Java and this may be a way to remove it.
I think it is very early days for GCJ though, so perhaps we need to wait a bit before it is fully usuable.
One Java compiler/runtime I may suggest looking at is Jikes (from IBM). I used it a few years ago and was very impressed. I'm not sure how well it plays with apache/java serverlets though.
I am pretty sure I have a Java run time environment from IBM installed at work in order to run the Oracle client tools (from the Oracle 8i). It seems to do this OK though there is some strangeness in that if one of these tools is run without a controlling terminal a java coredump occurs in one of the X libraries.
Steve.