Saw that Caolan keeps a blog describing the OpenOffice.org 2 progress with gcj. He is seeing great speedup from gcj4 native compiled code, but the build times for some parts of OOo are enormous:

Use gcj-dbtool during the build for gcj. This has a huge impact for me building multilanguage langpacks as helpcontent2 is a heavy java user, my experience is a 20hour build with interpreted bytecode and an 8 hour build with gcj-dbtool and -Dgnu.gcj.precompiled.db.path

Tom Tromey posted a status update on gcjx. Still a lot of work to be done for full 1.5 language support. But it looks like there is a lot of progress being made on replacing the current gcj frontend:

gcjx can parse all 1.4 and most 1.5 language features. […]
gcjx does pretty well on jacks – much better than gcj. I think I counted 70 gcj front end PRs that are fixed in gcjx. […]
As of today, I can compile most of libjava using the tree back end

Sad to see Ranjit struggling with non-free proprietary software while there is so much Free Software available to help with what he is trying to accomplish.

GNU Classpath class documentation currently only comes in HTML. But is generated using gjdoc which can also generate texinfo or raw xml. From that you can generate info, docbook, pdf, etc. Evince is just the GNOME frontend for the new freedesktop Poppler pdf renderer used by both the GNOME and KDE hackers. It is under active development. Netx a free JNLP implementation that just works with GNU Classpath based execution engines:

/usr/local/gcc40/bin/gij -jar netx-0.5.jar -jnlp http://www.acm.vt.edu/~jmaxwell/dvorak/Compare.jnlp

Back next week.

P.S. Ranjit see Evince for a free well integrated document viewer on GNU/Linux Gnome systems.

Dalibor published his Kaffe – Past, Present and Future presentation he gave during our Escape the Java Trap! Fosdem meeting. As people might remember there were some problems with his laptop at that time. So it is good to finally have the full text. Thanks Dalibor.

Sven de Marothy did it again. More and more stuff just works these days:

Just a oneliner fix to GNU Classpath and one for the application itself (usage of com.sun class, sigh).
Sven has more screenshots and build instructions.

We should have send this out earlier, but there was so much other stuff to do (Fosdem Meeting! and a little vacation). But it is finally done. The GNU Classpath 0.14 release announcement. The best thing about it is that we worked hard to get as much as possible merged with libgcj and kaffe for the upcoming GCC 4.0 (gcj) and Kaffe 1.1.5 releases. So looking at the 0.14 release should give you a pretty good indication about what will be hitting the distributions real soon now. Both GCC and Kaffe seem to be really used and tested by various GNU/Linux distributions as free JDK replacements which gives us all a very good feeling.

As always the progress is impressive. Between 2005/01/06 (0.13) and 2005/02/25 (0.14) there were 232 commits by 29 different people. Our sloccount score improved to 327,731 (140 pure source code lines - excluding documentation - per day). I was really impressed by our mauve scores. Mauve is growing fast. For 0.13 we had 23131 out of 23729 mauve tests PASSes. For 0.14 we have 25442 out of 25912.

Since we are into the 0.15 release cycle already we can look forward to lots of new things. Most notably the new jawt support (which is already in gcj and kaffe if you want to play with it), Audrius has been working on javax.swing.text.html and made a lot of mauve tests for it, and he has now started on the org.omg corba stuff, and Jeroen had a new ThreadLocal implementation that looked good. The next release will have all these goodies! In just 6 weeks from now :)

I really like going through the changes between releases to make these announcements and list everybody and everything that we have done. It is like going through an old photo book and remembering when what happened how. There is always more new stuff then I remember.

Robert Schuster made a show case page on the new developer.classpath.org wiki called ClasspathShowCase in which he shows some simple steps to convince people how much progress we have made in the last couple of years. Try it out today and get convinced.

Everything he shows will be included in the upcoming releases of Fedora Core 4 and Ubuntu Hoary real soon now!

Presentations Fosdem 2005
All presentations are now linked from
http://www.gnu.org/software/classpath/events/escape_fosdem05.html

Vacation!
I will be offline for a week! Yeah!

Photos of the GNU Classpath Fosdem 2005 meeting.

David Gilbert of JFreeChart fame posted two pictures to the GNU Classpath mailinglist that say more than a thousand words:

LugRadio

Sven de Marothy made it on LugRadio. He describes his experiences on the GNU Classpath mailinglist. It is interesting to see how these things work. I was mainly surprized about how the interviewers wanted it to be some fight between mono and GNU Classpath. While in reality mono is of course just one of the execution environments for GNU Classpath based programs through IKVM. They did reach an interesting conclusion though. There is so much free software out there written in the java programming language and GNU Classpath based compilers/runtimes like gcj can now support so many millions lines of code like eclipse, jonas, jakarta, etc that it is a very safe and solid choice to build upon (or as Sascha would say “it is the cobol of this millennium”, but that doesn’t sound as sexy).

JCVM

Normally I avoid introducing all the runtimes based on GNU Classpath since it seems to confuse non-core developers (see the above interview with Sven). People seem to be scared of choice. But the recent improvements of JCVM are impressive and drive home the point why we are better of with Free Software and the freedom of exploring various different execution models for free software.

JCVM has sometimes been described as a “poor man’s gcj” since it is a ahead of time compiler generating native code, but can only compile from .class files and actually generates C source files, not object code. It isn’t a “real” compiler like gcj which is embedded into the GNU Compiler Collection GCC, and uses the GCC framework to do most of its optimisations. JCVM optimizes the byte code and transforms them into C source files and lets gcc optimize the C source files which produces the ELF object files. Surprizingly (at least to me) this sometimes generates much faster code then gcj does. As seen by some optimization experiments done by Tzvetan Mikov. It will be interesting to see when such improvements will be carried over to GCC or other compiler frameworks.

If you haven’t read it, and you are interested in the issues and challenges of creating a execution model for programs written in the java programming language then you should read the JCVM Manual. It has a lot of very interesting low level details in it.