Is batik squiggle supposed to work?

I've been testing batik on and off with Classpath the last year, hoping it would make it to Debian/main and thus allow the OpenJump package to make it into Debian/main. But there are still issues. But I am starting to suspect that the problem isn't with Classpath, but with batik itself, as it

Re: Handling native libs within a Virtual Machine

Tom Marble writes: Juergen Kreileder wrote: Tom Marble wrote: Current Debian Java Policy [1] in section Chapter 2.1: Virtual Machines stipulates If a virtual machine supports native code, it must include the directory /usr/lib/jni in its search path for these dynamic libraries.

Re: Java policy change proposal: runtime/compiler selection

Tom Marble writes: Jeroen van Wolffelaar wrote: Currently, there is update-java-alternatives in java-common to manage the various java commands and how they refer to which implementation. People can however ignore it and update-alternatives themselves, things can get out-of-sync, and how

Re: Handling native libs within a Virtual Machine

Matthias Klose wrote: If I follow the instructions for Local installation [2] which keeping Debian Policy [3] in mind I then can do the following (to simulate local installations should never install directly into /usr, always in /usr/local. I think the Debian packaging guidelines are clear

Re: Java policy change proposal: runtime/compiler selection

Matthias Klose wrote: Tom Marble writes: Jeroen van Wolffelaar wrote: Currently, there is update-java-alternatives in java-common to manage the various java commands and how they refer to which implementation. People can however ignore it and update-alternatives themselves, things can get