[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ next ]
Currently Blackdown's, Sun's and Ibm's jvms work in Debian. (But, for simple programs such as the ones used for teaching, the free kaffe VM may be enough. Another solution is to use gcj and to compile to native code, thus solving the VM problem.)
All of them can be unpacked in /usr/local with links made in /usr/local/bin. This will work in any Debian setting and version, the only issue being is wether or not the version is glibc based or libc5-based regarding (older versions of Debian do not have glibc support since it was included in Debian 2.1 codename slink)
The following lists JVMs available in the latest Debian release (4.0, 'etch'):
kaffe
sablevm.
gij-4.1
If you want to look for available JVMs in a different release, this list can be reproduced with the command:
grep-available -F Provides -sPackage java-virtual-machine
.
Note that providing an API does not mean that everything is implemented, and certainly not implemented correctly. But even Sun's SDK, each out of four confirmed bugs don't get fixed, so don't disregard free implementation on buggyness or limited implementation alone.
Several APIs are compared for GNU Classpath, GNU gcj, Kaffe and Wonka with
japitools.
Yes, there are. Some of these are reported as Debian bugs. You can look up
the bugs for a specific Debian package at the Debian Bug Track System. As a
quick link, here are some packages:
As common within the Debian project, the developers would appreciate good bug
reports on found problems. These include the good description of the problem,
the command that gives the problem, the errors given when running the command,
and any other information that might be relevant. A good tool to report bugs
is reportbug.
No, you can try to run the applications without a jvm by compiling the source code to native code is.
You might be able to use gcj or jikes (both free
programs), to compile the program. And use gcj to convert
bytecode to native code. The entire software chain is free.
Most certainly, read in http://lists.debian.org/debian-java/1999/debian-java-199911/msg00044.html
how this was done for the XML parser xp.
ezili:~/infosystems/XML/Java> gcj --main=UnTag UnTag.java UnTagHandler.java
/usr/share/java/repository/org/xml/sax/helpers/*.class
/usr/share/java/repository/org/xml/sax/*.class /usr/share/java/repository/com/j
clark/xml/sax/*.class /usr/share/java/repository/com/jclark/xml/parse/*.class
/usr/share/java/repository/com/jclark/xml/tok/*.class
/usr/share/java/repository/com/jclark/util/*.class
/usr/share/java/repository/com/jclark/xml/parse/base/*.class
Yes there are also some problems.
gcj does not fully support JNI. Tom Tromey is responsible for the
JNI implementation. As of april 2000 it is missing one feature (you can't
currently compile a .class file that uses JNI functions to implement its native
methods), but Tom is working on this and hope to have it completed
"soon".
Lack of JNI affects use of Classpath (e.g. as an alternative to libgcj) as well as small, standalone apps that replace AWT with some really simple GUI (like using curses, e.g. for small installers). It also affects projects which have native code for performance reasons. At the moment, gcj basically forces a CNI port. The only alternative we are aware of is TowerJ, which is good for commercial projects, but does not offer anything to free software.
Possibly not, since libgcj does not build on sparc and no one has tried this for arm.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ next ]
Debian GNU/Linux Java FAQ.
[email protected]