Re: Stallman lamenting that GCJ and ClassPath are still (read: eternally)catching up ...

[Dalibor Topic <robilad at kaffe dot org>]

Hi Christopher,

Christopher Marshall wrote:
> In terms of "useful things it can do", gcj is ahead of Sun in some ways, is it not?  The license
> and the ability to compile to native exectuables, for example.  Does gcj support more
> architectures?  If it did, that would be worth singing about.  It would be a good piece of
> advocacy to generate a more complete list of things gcj can do that Sun can't.  It would also be
> nice to have some testimonials about how someone was able to solve a problem using gcj that they
> couldn't using Sun's JDK.

I'm not a gcj developer, so fear I can not adequately praise gcj 
developers for their great successes so far. I'll take the spin from the 
GNU Classpath angle, though, viewed through the slighlty skewed lens of 
a kaffe developer. :) I hope that's still apropriate in this forum.

* OSS arguments

Kaffe uses large parts of GNU Classpath, and has been ported [1] to some 
50+ platforms (in the CVS, another 10-20 haven't been merged in) which 
mean your java programs will run pretty much the same on those 50 
platforms [2]. I assume that gcj runs also on a ton of platforms, where 
no JDK has gone before. There is the 'real write-once-run-everywhere 
through GNU Classpath' argument :)

You can also strip down the class library down to the bare minimum for 
your application and distribute the result, something you can not do 
with Sun's code afaik. We've got class library profiles for that in 
kaffe, I assume it would be fairly easy to implement in gcj.

Gcj, Kaffe and other free runtimes usually support several AWT backends 
(Xlib, gtk+ for gcj, Xlib and Qt2/3/Embedded for Kaffe, ~10 others for 
Pocketlinux kaffe). They can also offer choice wrt to threading (posix, 
platform-native or vm-managed/green).

Performance *can* be quite a bit better on a free VM than on a non-free 
counterpart. One of the main arguments for pushing NIO into Kaffe via 
Classpath was to make sure we can run freenet again [3]. Freenet 
developers loved the performance gains they got with kaffe's GNU MP 
based java.math.* package over Sun's pure java one, though I don't have 
benchmarks to throw around. gcj-ed code can be faster than interpreted 
or jitted code.

* free software arguments

Security of investment: other than a non-free implementation, sponsored 
by a financially shaky company, free software runtimes are here to stay, 
and won't disappear if, for example, Red Hat files for bankrupcy. 
Kaffe's backing company, Transvirtual, folded in summer 2002, but 
Kaffe.org developement didn't stop at all. I'd even say it's stronger 
now, than in the last 3-4 years.

Enterprise software stack: If you don't have control over all cards in 
your card stack, you may have to change your design, or implementation 
long after the release. To take a very imaginative, hypothetical 
example: If Sun runs out of money, and deperately decides to charge a 
Java runtime license a la SCO and simply terminates all previous 'free 
as in beer' licenses, then a lot of companies will be having a hard time 
scrapping for an alternative for their investments. Such hypothetical 
scenarios would not be possible with free runtimes, since even if Red 
Hat would decide to charge for gcj-4.0, they couldn't take away your 
right to use gcj 3.9.9.

> That was my take on it also.  Stallman's article was pretty good.  Part of it did seem more like a
> plea for help though (help us before the forces of evil extinguish us once and for all!  we are so
> fragile!), when it could have sounded like a "look what we can do and they can't" piece.

Well, we could use some help for the other ~50 % of the JDK 1.4 API :) I 
think it's quite important to attract the 'java-using, free software 
loving developer' demographic to projects like GNU Classpath and gcj, 
since your typical java user is as likely to switch from Sun's JDK to 
gcj as he's likely to switch from Windows XP to RHEL [4] :)

And judging by the amount of free software java projects out there on 
freshmeat.net that don't work with Kaffe, gcj or other GNU Classpath 
based runtimes, I assume there are quite a few free software java 
developers out there, that would make great allies on the road to the 
other 50%, if they could be reached :)

> On another note, java has more APIs and classes in its standard libraries than a dog has fleas.  I
> wonder how many of those classes are used by most java projects/programmers out there?

That depends on your project. Some projects use just about everything 
under the sun :) This is the relevant excerpt of import statements in 
ant 1.6.1, for example:

import java.awt.BasicStroke;
[snip]
import java.awt.event.ActionEvent;
[snip]
import java.awt.geom.Arc2D;
[snip]
import java.awt.geom.Ellipse2D;
import java.awt.image.BufferedImage;
import java.awt.image.renderable.ParameterBlock;
[snip]
import java.beans.PropertyChangeListener;
[snip]
import java.io.BufferedInputStream;
[snip]
import java.lang.reflect.Constructor;
[snip]
import java.lang.ref.WeakReference;
[snip]
import java.net.HttpURLConnection;
[snip]
import java.rmi.Remote;
import java.security.DigestInputStream;
[snip]
import java.sql.Connection;
[snip]
import java.text.CharacterIterator;
[snip]
import java.util.ArrayList;
[snip]
import java.util.Arrays;
[snip]
import java.util.jar.Attributes;
[snip]
import java.util.regex.Matcher;
[snip]
import java.util.regex.Pattern;
[snip]
import java.util.zip.CRC32;
[snip]
import javax.activation.DataHandler;
[snip]
import javax.sound.sampled.AudioFormat;
[snip]
import javax.swing.BorderFactory;
[snip]
import javax.xml.parsers.DocumentBuilder;
[snip]
import javax.xml.transform.dom.DOMSource;
[snip]
import javax.xml.transform.sax.SAXSource;
[snip]
import javax.xml.transform.Source;
[snip]
import javax.xml.transform.stream.StreamResult;
[snip]
import org.w3c.dom.Attr;
[snip]
import org.xml.sax.AttributeList;
[snip]
import org.xml.sax.helpers.AttributeListImpl;
[snip]

I've snipped out various classes from already mentioned packages. But 
you can see how a releatively small [5] program like ant utilizes more 
than 30 packages already.

cheers,
dalibor topic

[1] That doesn't mean it works surprisingly well, it just means it has 
been ported :)
[2] Modulo bugs, crashes, etc. :)
[3] I haven't tried the latest changes from Michael Koch yet, I'll 
report later
[4] Yeah, I know, I'm stretching the metaphor quite a bit here ... 
Nevertheless, a lot of OSS java development (i.e. apache) seems to take 
place on Windows.
[5] Well, in comparison with JBoss for example :)