Node:Getting Started, Next:Jasper Package Options, Previous:Supported Java Versions, Up:Jasper Notes
This section describes some tips and hints on how to get the interface started. This is actually where most problems occur.
Under Windows, you should add SICStus Prolog's and Java's DLL
directories to your %PATH%
. This will enable Windows library
search method to locate all relevant DLLs. For SICStus, this is the same
as where sicstus.exe
is located, usually
C:\Program Files\SICStus Prolog 3.9.1\bin
.
For Java, it is usually
C:\jdk1.3.1\jre\bin\hotspot
(for JDK
1.2.2 it would be C:\jdk1.2.2\jre\bin\classic
).
For example (Windows NT/2000/XP):
set PATH=C:\jdk1.3.1\jre\bin\hotspot;%PATH% set PATH=C:\Program Files\SICStus Prolog 3.9.1\bin;%PATH%
When library(jasper)
is used to embed Java in a SICStus
development system or run-time system, then the run-time linker needs to
be told where to find the Java libraries (e.g.
libjvm.so
). During installation, InstallSICStus
will build
either the sicstus
executable or the jasper
foreign resource
so that it contains the necessary
information; the detail are platform dependent.
If you use spld
to relink SICStus or to build a
run-time system, you can use the command line option
--resource=-jasper
(note the minus sign).
This tells spld
to include the search
path (rpath) in the executable needed to ensure that
library(jasper)
can find the Java libraries.
If you want to run sicstus
with another Java than what was
specified during installation, you can use spld
without the
--resources
option to get a SICStus executable without any
embedded Java paths. In this case, you need to set the environment
variable LD_LIBRARY_PATH
(or similar) appropriately. One example
of this is to use the JDK 1.3 server version instead of the default
(client) version.
Alternatively, you can use spld
with the
--resource=-jasper
and --with-jdk=DIR
options to
generate a development system with embedded paths to another Java
directory tree. This will only work if the alternative directory tree has
the same structure as the JDK directory seen by InstallSICStus
.
If SICStus is used as parent application, things are usually really
simple. Just execute the query | ?- use_module(library(jasper)).
.
After that, it is possible to perform meta-calls as described in
Jasper Library Predicates.
On UNIX, you may encounter the following error message:
% sicstus SICStus 3.8 (sparc-solaris-5.5.1): Wed Sep 22 08:42:14 MET DST 1999 Licensed to SICS | ?- use_module(library(jasper)). [...] {SYSTEM ERROR: 'Attempted to load Java engine into sbrk\'d SICStus system (try starting SICStus with -m option)'} [...]
Since most platforms don't allow sbrk()
and malloc()
(or
threads) to coexist peacefully, SICStus refuses to load the JVM if not the -m
flag was given to SICStus. The message can, as the error message
suggests, be avoided if SICStus is started with the -m
flag:
% sicstus -mThe
-m
flag is not needed, and is ignored, on
Windows.
When Jasper is used in run-time systems, additional constraints apply as
described in Runtime Systems on Target Machines. The Java to
SICStus interface relies on dynamically loading the SICStus run-time
system. For this reason, it is not possible to use library(jasper)
from an executable that links statically with the SICStus run-time.
If Java is used as parent application, things are a little more
complicated. There are a couple of things which 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")
. The loadLibrary
method uses a platform
dependent search method to locate the Jasper native library, and quite
often this method fails. 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)
On 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 [...]
On Windows, Java must be able to find spnative.dll
through the
PATH
environment variables and setting -Djava.library.path
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 runtime
library (i.e. sprt.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.9
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.9.1" \ -classpath "/usr/local/lib/sicstus-3.9.1/bin/jasper.jar" \ se.sics.jasper.SICStus Trying to load SICStus. If you see this message, you have successfully initialized the SICStus Prolog engine.
On Windows, it would look something like this, depending on the shell used:
% java -classpath "C:/Program Files/SICStus Prolog 3.9.1/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. libsprt39_instance_01_.so
,
need to be available as well. See Runtime Systems on Target Machines.