## Metagnostic home
| # JNIPort for Dolphin Smalltalk
Overview Contents Players Layers Examples Configuration InFAQ Changes Licence Back to Goodies | # JNIPort and JVMs This section is about which JVMs JNIPort has been tested against. I have tried no other JVMs at all. Each JVM implementation comes with its own way of locating the runtime (since Sun didn't even bother to set up a decent convention, let alone a proper specification, for how to do this). The corresponding subclasses of JNILibrary differ only in that they understand the different vendors' conventions. If you explicitly specify the location of the JVM DLL in the configuration, then the conventions are ignored and there is no effective difference between the versions of JNILibrary. If you try another JVM implementation then please do let me know how you get on. Note that JNIPort requires an implementation of JNI that is compatible with (at least) the 1.2.x release from Sun. ## Sun JVMs I've used the Sun JVMs almost exclusively as I've been writing JNIPort. It really requires a 1.4.x version of the JVM to work fully. The 1.3.x series also worked when I last used them, but there were a few bugs. I can't remember exactly what; I think there were some problems with accessing static fields inherited from interfaces. Also the -verbose:jni option caused the JVM to issue thousands of warnings about exceeding the capacity of the local pool (the warnings were wrong, but irritating nonetheless). A very early version of JNIPort was based on 1.2.x, but there were endless problems and instabilities — the problems were mostly with Sun's code (their floating-point handling), but it might be that current JNIPort, and a recent Dolphin VM, could be made to work with it. The Sun JVM's have always had a problem with floating point exceptions. The picture has improved over time, partly because Sun have worked on the problems, but also because, since version 5, Dolphin now suppresses floating point underflow errors by default (it was always intended to, but the default was set wrongly). The Sun JVM seems to require that both underflow and overflow exceptions are turned off or else it fails intermittently on floating point operations that generate the error. To turn off overflow trapping, execute this Dolphin code:
    	active := Processor activeProcess.
    	fpeMask := active fpeMask: (active fpeMask | _EM_OVERFLOW).
    	...some code which might overflow...
    	active fpeMask: fpeMask.
The constant, `_EM_OVERFLOW`, is defined in the pool constants dictionary `CRTConstants`. ## IBM JVMs I've tested briefly against the IBM JVM for Windows. It seems to work OK. There are a couple of bugs in the JVM that show up in the regression tests, but these are because of a really obscure part of the JVM semantics that IBM have got wrong. It shouldn't affect anything in practice. The most recent IBM version that I've tried is 1.3.x, so there may be a later version with the bug fixed. Since the IBM implementation for Windows seems to be based on Sun's code, it shares the same irritating tendency to witter on about the local pool. I haven't tested extensively, but it appears that the IBM JVM does not share Sun's problems with floating point exceptions. ## BEA JVMs (JRockit) I've tested briefly against version 7 of the JRockit JVM from BEA Weblogic. It almost works, but there is a nasty bug in their implementation of `java.lang.Class.declaredMethods()` (and similar) when called directly from JNI. JNIPort includes a patch in package 'CU JRockit Patch' — see the package comment for how to install it (loading the package does not automatically install the patch). BEA released version 8 of JRockit recently, but I haven't had time to try it, so I don't know whether they've fixed the bug, they hadn't in the beta of version 8. With the patch, the picture is very much the same as with IBM. There are a couple of obscure bugs and incompatibilities with Sun's JVM, but nothing very major. The BEA JVM appears to suffer from the same floating point failures as Sun's. Only worse — the failure crashes Dolphin rather than simply aborting the Java runtime.

Copyright © Chris Uppal, 2003-2005

Java, JNI (probably), JVM (possibly), and God knows what else, are trademarks of Sun Microsystems, Inc.