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

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 a

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,

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 li

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 fa