java-gcj-compat status

I submitted my ecj option parsing patch to Eclipse.

The patch went into Rawhide’s eclipse-ecj last night, which meant I was able to remove the last option munging stuff from java-gcj-compat. Behold:


$ ls -l /usr/lib/jvm/java-gcj/bin
jar -> /usr/bin/fastjar
java -> /usr/bin/gij
javac -> /usr/bin/ecj
javadoc -> /usr/bin/gjdoc
javah -> /usr/bin/gjnih
rmic -> /usr/bin/grmic
rmiregistry -> /usr/bin/grmiregistry

No wrapper scripts, just direct symlinks. All these tools are now command-line compatible with their proprietary equivalents.

java-gcj-compat’s remaining holes are representative of the entire free stack’s J2SE deficiencies. Specifically:

  1. dependencies on external crypto providers
  2. no CORBA tools
  3. no Java plugin

These are the areas that we need to focus on this year. 1 should be pretty easy; just a matter of merging GNU Crypto, Jessie and Bouncy Castle into GNU Classpath. 2 will be harder. Ideally we could get JacORB dual-licensed LGPL/GPL+exception, reimplement all the non-free OMG headers it uses and merge it into GNU Classpath. Quite a bit of effort. 3 will be harder still; we’ll need to finish libgcj’s security implementation (with test suites and everything) and fix many bugs in our AWT and Swing implementations.

AWT buffer strategies

I finished GNU Classpath’s BufferStrategy framework tonight:

AWT BufferStrategy test.

Currently there is only one unaccelerated backend that doesn’t actually do anything, but the framework for adding new backends is in place as well as all the necessary documentation.

This patch adds the missing methods that Caolan mentioned in his blog. This is the last GCJ AWT vs. OO.org problem I’m aware of, so I think we’re in good shape for Fedora Core 4.