Node:Running SICStus from Java, Previous:Running Java from SICStus, Up:Getting Started

Running SICStus from Java

If Java is used as parent application, things are a little more complicated. There are a couple of things that need to be taken care of. The first is to specify the correct class path so that Java can find the Jasper classes (SICStus, SPTerm, and so on). This is done by specifying the pathname of the file jasper.jar:

% java -classpath $SP_PATH/bin/jasper.jar ...

SP_PATH does not need to be set; it is only used here as a placeholder. See the documentation of the Java implementation for more info on how to set classpaths.

The second is to specify where Java should find the Jasper native library (libspnative.so or spnative.dll), which the SICStus class loads into the JVM by invoking the method System.loadLibrary("spnative"). Under UNIX, Jasper can usually figure this out by itself, but in the event that Jasper is used in a non-standard installation, this will most likely fail. A typical example of such a failure looks like:

% java -classpath [...]/jasper.jar se.sics.jasper.SICStus
Trying to load SICStus.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no spnative
in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1133)
	at java.lang.Runtime.loadLibrary0(Runtime.java:470)
	at java.lang.System.loadLibrary(System.java:745)
	at se.sics.jasper.SICStus.loadNativeCode(SICStus.java:37)
	at se.sics.jasper.SICStus.initSICStus(SICStus.java:80)
	at se.sics.jasper.SICStus.<init>(SICStus.java:111)
	at se.sics.jasper.SICStus.main(SICStus.java:25)

Under UNIX, this can be fixed by explicitly setting the Java property java.library.path to the location of libspnative.so, like this:

% java -Djava.library.path=/usr/local/lib [...]

Under Windows, Java must be able to find spnative.dll through the PATH environment variable (see Windows). Setting -Djava.library.path under Windows can lead to problems if multiple versions of SICStus has been installed.

If this works properly, SICStus should have been loaded into the JVM address space. The only thing left is to tell SICStus where the (extended) runtime library, sprt.sav (spre.sav), is located. On those platforms where the SICStus run-time system can determine its own location, e.g. Windows, Solaris and Linux, the run-time system will find the runtime library automatically. Otherwise, you may choose to specify this explicitly by either giving a second argument when initializing the SICStus object or by specifying the property sicstus.path:

Example (UNIX):

% java -Dsicstus.path=/usr/local/lib/sicstus-3.12.0

If you do not specify any explicit path, SICStus will search for the runtime library itself.

If everything is set up correctly, you should be able to call main (which contains a short piece of test-code) in the SICStus root class, something like this:

% java -Djava.library.path="/usr/local/lib" \
       -Dsicstus.path="/usr/local/lib/sicstus-3.12.0" \
       -classpath "/usr/local/lib/sicstus-3.12.0/bin/jasper.jar" \
        se.sics.jasper.SICStus
Trying to load SICStus.
If you see this message, you have successfully
initialized the SICStus Prolog engine.

Under Windows, it would look something like this, depending on the shell used:

% java -classpath "C:/Program Files/SICStus Prolog 3.12.0/bin/jasper.jar" se.sics.jasper.SICStus
Trying to load SICStus.
If you see this message, you have successfully
initialized the SICStus Prolog engine.

If more than one se.sics.jasper.SICStus instance will be created, then the SICStus run-times named e.g. sprt312_instance_01_.dll, need to be available as well. See Runtime Systems on Target Machines.