GCC 4.0.0 Released, Supports Free Software Java
When GNU announced the release of GCC 4.0.0 four days ago, the Java community paid little attention. The prevailing sentiment is "Nah, it's a C++ compiler, whatever!"
And that would be a huge mistake, for GCC 4.0.0 includes a complete Java compiler and an almost complete set of the standard Java libraries. AWT and Swing are progressing rapidly in the GNU Classpath project, which provides the Java class library for GCJ and other JavaVM projects!
When I last wrote about GCJ, the Java compiler in GCC, 844 days ago, the compiler just started to build under the mingw tool chain, and Eclipse made its first run under GCJs Java interpreter, gij after some tweaking of both GCJ and Eclipse.
When I tested out the latest GCC yesterday, paying attention to the Java stack, I was really impressed with the progress the GCJ folks has made in the last two and half years. Almost all of my existing Java sources that compile with Sun JDK 1.4 also compiles with GCJ. AWT based GUI programs (such as those found in Java In a Nutshell, 1st and 2nd edition) runs on my Fedora Core 3, as native programs, using the GTK based peers. Eclipse can now be compiled with GCJ, into a native program on Linux. And it will ship with Fedora Core 4, scheduled for June 4, 2005!
Being part of GCC, GCJ compiled native code can be debugged with gdb, profiled with gprof. Although not yet working, it should be possible to generate coverage information for GCJ compiled application with gcov.
GCJ fulfills the needs for Java in many situations where the Sun JDK does not because of its licensing schemes. While Sun's goal of keeping its Java compatible is a noble one, in practical terms it has produced much forking and alternative implementations:
- Microsoft's DotNET (because the Sun license is not good enough for Microsoft)
- Eclipse and SWT (because the JCP process is not good enough for folks at IBM)
- JBoss (can't claim to be J2EE compatible for a long time)
- GCJ+Classpath (because the Sun license does not allow the JDK to be distributed with Linux distributions)
My prediction is that before long, Java library writers, especially the Open Source and Free Software ones, will care that their library compiles both with the Sun JDK and GCJ.
And a couple of years from now, we may wake up in a world where GCJ dominates in the Free Software realm while proprietary JDKs dominate in Enterprise computing.
Re: GCC 4.0.0 Released, Supports Free Software Java
Re: GCC 4.0.0 Released, Supports Free Software Java
Re: GCC 4.0.0 Released, Supports Free Software Java
At the end of the day, it's the applications that matter. That is true for operating systems, programming languages or GUI toolkits.
I believe Classpath's AWT/Swing implementation is at the stage where a wider group of developers (GUI application developers themselves, mostly) may start trying it out and reporting bugs and contributing patches. That's the only way it can become more fully implemented and compliant.
The success of things like Classpath is measured not by the percentage of JDK classes that it implements, but by the number of applications that it can compile and run. If there is a paucity of Swing applications to start with, the progress of Classpath's AWT/Swing stack will be slower. But then again we are not missing too much with that slowness.
In the mean time, you can already write Gtk+/GNOME applications with Java-GNOME, or even SWT applications with GCJ.
Re: GCC 4.0.0 Released, Supports Free Software Java
Nothing against GCJ/classpath but the Sun license doesn't actually state that. It says for the JDK, the redistribution needs to be delivered as part of a Java program. Some distributions choose not to distribute it on their licensing terms which is fair enough.
Ideally the license should make it clearer of the intent. The original intent I believe was to prevent downloads of just the JDK from other sites instead of Sun.
Re: GCC 4.0.0 Released, Supports Free Software Java
Thanks for the comment Calvin.
I'm referring to the fact that to this day, Linux distributions like Red Hat and Debian cannot include Java like they included Perl or Python or Ruby or Tcl/Tk.
I guess it's a combination of Sun's License and Red Hat or Debian's policies that prevented Java's inclusion. I'm not blaming it all on Sun. (It's Sun code and they have the right to license it however they want.)
However, Sun's experimentation with a few different licenses for the next version of Java seems to indicate that Sun realizes that there are problems with its license.
But if past experience is any indication, Sun will stay a hair's width away from making Java Open Source compatible. Just to annoy Richard Stallman, I'm sure. :)