Jasper requires at least Java 2 to run. Except under Windows the full development kit, not just the JRE, is needed. Jasper does not work with Visual J++ or Visual Café. Unless indicated otherwise, you can download the JDK from http://java.sun.com.
Except where indicated, Jasper is built with JDK 1.3.1 and is expected to work with the latest version of JDK 1.4.
Jasper is only supported under the following configurations:
Note that JDK 1.4 is required for 64 bit SPARC Solaris.
There is a bug in Sun JDK 1.3.1 that surfaces when sicstus is the
top-level executable, e.g., sicstus -l
library/jasper/examples/jqueens.pl. The symptom similar to:
java.lang.UnsatisfiedLinkError: exception occurred in JNI_OnLoad
...
at java.awt.Component.<clinit>(Component.java:356)
...
The underlying problem is that motif21/libmawt.so cannot find
libmlib_image.so A work-around for SPARC is to set
LD_LIBRARY_PATH to java-install-dir/jre/lib/sparc
before invoking sicstus. A similar work-around should work on
x86. This bug is not present in JDK 1.4.1.
Sun's JDK 1.2.2 does not support native threads and therefore does not work.
sicstus).
Note that this is a problem only with development systems. SICStus run-time systems do not use signals, (e.g. when embedding SICStus in Java using the Jasper package.)
Most of the signal handlers used by the SICStus development system
(sicstus) are now turned off
automatically before library(jasper) starts Java. In JDK 1.3.1 the problem with conflicting uses of signals
was recognized and the Java initialization option -Xrs
was added to reduce Java's use of signals.
It makes JDK use signals in a way that is compatible with
the SICStus development system.
There are several ways to pass this flag to Java. The recommended way is
to pass it with jasper_initialize:
bash> sicstus
...
| ?- use_module(library(jasper)),
jasper_initialize(['-Xrs', <other options here>], JVM).
Alternatively, you can pass it using the (not documented in the
JDK documentation) environment variable _JAVA_OPTIONS:
bash> export _JAVA_OPTIONS='-Xrs'
bash> sicstus
Using _JAVA_OPTIONS is currently the only way to pass
this flag if you rely on the automatic Java initialization done when
invoking a Java foreign resource.
JDK 1.4.1 is now available for MacOS X. It does not work well
when SICStus is the top-level application, e.g., when using the
SICStus development system. In particular, opening GUI components such
as Swing, will hang. The cause for this is not known. One work-around is
to force the use of JDK 1.3.1 by setting the environment variable
DYLD_LIBRARY_PATH before invoking SICStus.
bash> export DYLD_LIBRARY_PATH=/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Libraries
bash> sicstus -i
DYLD_LIBRARY_PATH be
set up so that Java can find the SICStus run-time library. That is, you
may need to set DYLD_LIBRARY_PATH to the location of the SICStus
run-time libsprt311.dylib.
java -fast64) of JDK 1.3.1 is
supported. Also see the Linux entry above.
LD_LIBRARY_PATH to the directory where the SICStus run-time
library is located (e.g. /usr/local/lib).
Sun's JDK 1.2.2 and JDK 1.4.x are also expected to work, but
are not tested.
The AIX version of JDK 1.3.1 requires some environment variables to
be set before invoking an application that embeds the Java VM. For this
reason, the following environment variables should be set before starting
a SICStus executable that uses library(jasper):
bash$ export AIXTHREAD_SCOPE=S
bash$ export AIXTHREAD_MUTEX_DEBUG=OFF
bash$ export AIXTHREAD_RWLOCK_DEBUG=OFF
bash$ export AIXTHREAD_COND_DEBUG=OFF
bash$ export LDR_CNTRL=USERREGS
bash$ sicstus
...
See the AIX JDK 1.3.1 readme (/usr/java131/README.HTML) for futher details.
You will need to set LD_PRELOAD to the location of libjvm.so
before invoking sicstus in order to use
library(jasper). For instance, to start 64bit sicstus with JDK
1.4.1
bash$ LD_PRELOAD=/opt/java1.4/jre/lib/IA64W/server/libjvm.so sicstus -i
This is not an issue when Java is the top-level application.