This page collects information around making the products of the Apache XML Graphics compatible to GNU Classpath (and related packages).

What's the fuss about?

Several parties, especially from the Fedora core, Debian and Wikipedia corners, would like to make use of Batik and FOP on a Free Software tool stack. This is currently not entirely possible as both products cannot be compiled using GCC/GCJ/GNUClasspath.

Many of the free JVMs out there (see GNU Classpath's JVM list) are based on GNU Classpath. GCC/GCJ can be used to compile a Java application to native code which many people would prefer and have repeatedly asked on our mailing lists. IKVM could be used to run and directly interact with Batik and FOP in a .NET environment.

What are the problems?

Apache XML Graphics

In Apache Batik, all direct dependencies on Sun-private classes like the JPEG codec (com.sun.image.*) have been hidden behind an interface. ImageIO alternatives are now available in SVN Trunk. Apache Batik should be ready to be compiled against GNU Classpath. We now only need someone to try it and report back the results.

The ImageWriter abstraction has already been ported to the new XML Graphics Commons project but Batik hasn't move over, yet.

GNU Classpath

These are the GNU Classpath bugs that have been identified so far as needing to be resolved before Batik will work:

29246 - Toolkit.getLockingKeyState(int) not implemented
Status: Patch has been supplied.

These are the GNU Classpath bugs that have been identified so far as needing to be resolved before FOP will work:

None identified.

IKVM

AWT support is quite limited at the moment. Jeremias Märki experienced problems compiling Batik using ikvmc. Details will follow. FOP Trunk, forcefully stripped from all dependencies on Batik, compiled and worked fine in an initial test for PDF output (see [3]).