help info jess-users endas the body of the message. There is an archive of the list at http://www.mail-archive.com/jess-users@sandia.gov .
Therefore, I am going to assume that you, the reader, are a programmer who will be using either one or both of these languages. I will assume that all readers have at least a minimal facility with Java. You must have a Java compiler and runtime system, and you must know how to use it at least in a simple way. You should know how to use it to
For those readers who are going to program in the Jess language, I assume general familiarity with the principles of programming. I will describe the entire Jess language, so no familiarity with LISP is required. Furthermore, I will attempt to describe, to the extent possible, the important concepts of rule-based systems as they apply to Jess. Again, though, I will assume that the reader has some familiarity with these concepts and more. If you are unfamiliar with rule-based systems, you may want to purchase a text on this topic as well.
Many readers will want to extend Jess' capabilities by either adding commands (written in Java) to the Jess language, or embedding the Jess library in a Java application. Others will want to use the Jess language's Java integration capabilities to call Java functions from Jess language programs. In sections of this document targeted towards these readers, I will assume moderate knowledge of Java programming. I will not teach any aspects of the Java language. The interested reader is once again referred to your local bookstore.
This document contains a bibliography wherein a number of books on all these topics are listed.
gunzip Jess60.tgz
tar xf Jess60.tar
If you downloaded Jess for Windows, you get a .zip file which should be
unzipped using a Win32-aware unzip program like WinZip. Don't use PKUNZIP since it
cannot handle long file names.
When Jess is unpacked, you should have a directory named Jess60/. There are two kinds of Jess distributions: binary-only and source. Inside this directory should be the following files and subdirectories, depending on which type of distribution you have:
| docs/ | This documentation |
| jess/ | A directory containing the jess package. There are many source files in here that implement Jess's inference engine. Others implement a number of Jess GUIs and command-line interfaces. Main.java implements the Jess command-line interface. Console.java is a very simple GUI console for Jess; ConsoleApplet.java is an applet version of the same. If you have a binary-only distribution of Jess, this directory will contain only the examples subdirectory. |
| examples/ | A directory of tiny example Jess files. |
| jess/examples | A directory of more complicated examples, containing example Java source files. |
| jess.jar (optional) | A Java archive file containing the Jess classes themselves. Binary distribution only. |
| Makefile (optional) | A simple makefile for Jess. Source distribution only. |
javac -d . jess\*.java javac -d . jess\awt\*.java javac -d . jess\factory\*.javawould work just fine, given that Jess60/ is your current directory. If you have problems, be sure that if you have the CLASSPATH environment variable set, it includes '.', the current directory. Don't try to compile from inside the Jess60/jess/ directory; it won't work.
If you're on a UNIX system instead of a Windows system, you can use the commands given above, but you'll need to change the backslashes (\) into forward slashes (/).
You must use a Java 2 compiler to compile Jess. The resulting code will run on any Java 2 or later VM. Jess works great with JDK 1.3.
There are a number of optional example source files in the subdirectories Jess60/jess/examples/ that aren't compiled if you follow the instructions above. You can compile the examples one at a time. For example, to compile the example named pumps using the JDK on a Windows system, you can use the command
javac -d . jess\examples\pumps\*.java
Again, don't set your current directory to, for example, Jess60/jess/examples/pumps/ to compile the pumps example: it will not work. The compiler will report all sorts of errors about classes not being found and the jess package not being found. Compile everything from the Jess60 directory. I can't stress this enough: this is by far the most common problem people have in getting started with Jess!
java jess.Main examples/fullmab.clp(if you've got a source distribution) or
java -classpath jess.jar jess.Main examples/fullmab.clp(if you've got a binary-only distribution) and the problem should run, producing a few screens of output. Any file of Jess code can be run this way. Many simple CLIPS programs will also run unchanged in Jess. Note that giving Jess a file name on the command line is like using the batch command in CLIPS. Therefore, you generally need to make sure that the file ends with:
(reset) (run)or no rules will fire. The zebra.clp and wordgame.clp programs are two classic CLIPS examples selected to show how Jess deals with tough situations. These examples both generate large numbers of partial pattern matches, so they are slow and use up a lot of memory. Other examples include sticks.clp (an interactive game), frame.clp (a demo of building a graphical interface using Jess's Java integration capabilities), and animal.clp. Note that animal.clp is hardwired to expect a data file to exist in a subdirectory examples/ of the current directory.
In the jess/examples/* subdirectories, you will find some more complex examples, all of which contain both Java and Jess code. As such, these are generally examples of how to tie Jess and Java together. The Pumps examples is a full working program that demonstrates how Jess rules can react to the properties of Java Beans.
Jess> (batch examples/sticks.clp) Who moves first (Computer: c Human: h)?Note that in the preceding example, you type what follows the Jess> prompt, and Jess responds with the text on the next line. I will follow this convention throughout this manual.
You can use the Jess system command to invoke an editor from the Jess command line to edit a file of Jess code before reading it in with batch. system also helps to allow non-Java programmers to integrate Jess with other applications. Given that you have an application named xlogo on your system, try:
Jess> (system xlogo &) <External-Address:java.lang.UNIXProcess>The & character makes the program run in the background. Omitting it will keep the system command from returning until the called program exits. The system command returns the Java Process object representing the launched application.
The class jess.Console is a graphical version of the Jess command-line interface. You type into a text field at the bottom of the window, and output appears in a scrolling window above. Type java jess.Console to try it.
Since Jess 6 uses the Java 2 API, it won't work in the native JVM of most deployed web browsers. Netscape 4.x and all versions of Microsoft Internet Explorer use some version of a JDK 1.1 Java Virtual Machine. You can use Jess 4 or 5 in these browsers, or you can require the user to download the Java Plug-In. A full discussion of this topic is beyond the scope of this document -- you're encouraged to get a book that covers deploying applets on the Web if you're interested.
Note that even in Jess 4 and 5, the ConsoleApplet and ConsoleDisplay classes use the Java 1.1 event model, which is still not supported by some of the installed base of Web browsers; the Plug-in might still be necessary. Don't use ConsoleApplet if you want to deploy highly portable applets! Actually, the idea of deploying Jess as an applet makes less and less sense these days; a much better alternative is to run Jess on the server side (as a servlet, for example) and run only the GUI on the client. Good applets are generally very small (a few tens of kilobytes), while Jess's class files now occupy hundreds of kilobytes.But the Jess language is also a general-purpose programing language, and furthermore, it can directly access all Java classes and libraries. For this reason, Jess is also frequently used as a dynamic scripting or rapid application development environment. While Java code generally must be compiled before it can be run, a line of Jess code is executed immediately upon being typed. This allows you to experiment with Java APIs interactively, and build up large programs incrementally. It is also very easy to extend the Jess language with new commands written in Java or in Jess itself, and so the Jess language can be customized for specific applications.
Jess is therefore useful in a wide range of situations. One application for which Jess is not so well suited is as an applet intended for Internet use. Jess's size (a few hundred kilobytes of compiled code) makes it too large for applet use except on high-speed LANs. Furthermore, some of Jess's capabilities are lost when it is used in a browser: for example, access to Java APIs from the Jess language may not work at all due to security restrictions in some browsers. When building Web-based applications using Jess, you should strongly consider using Jess on the server side (in a servlet, for example.)
human(Socrates). mortal(X) :- human(X).you might be interested in knowing if mortal(Socrates) was true. Prolog uses the rules to find it by looking for human(Socrates). Note that if you forget the result and ask for it again, Prolog has to compute it again. The central concept in Jess, though, is forwards chaining. Here, you have
Jess> (assert (human Socrates)) Jess> (defrule mortal (human ?X) => (assert (mortal ?X))) Jess> (watch facts) Jess> (run) ==> f-1 (MAIN::mortal Socrates) 1You don't specifically want to know (mortal Socrates) but rather you want to know what happens given that (human Socrates) is known. (mortal Socrates) is a result. After the rule has fired, (mortal Socrates) is known, and the rule mortal never has to assert this fact again. One more difference is that Prolog is really meant to be used from the console; i.e., you're actually supposed to sit down and type mortal(Socrates). In Jess, only developers do this; the command line is not intended for end-users. Prolog is really about answering queries, while Jess is about acting in response to inputs. Jess is different than some Rete-based systems in that it includes both a kind of backwards chaining and a construct called defquery which lets you make direct queries of the knowledge base. Both of these help Jess a better fit for some Prolog applications, but they don't make Jess into a Prolog-like system. Prolog is optimized, in a sense, for space, at the cost of speed. Jess (and its Rete algorithm) is optimized for speed at the cost of space. The Rete algorithm is all about computing things -once- so they never need to be recomputed, and then reusing them. Prolog's approach is targeted at exploring large numbers of possibilities once, while Rete is aimed at exploring medium-sized numbers of possibilities repeatedly. Regarding different ways to express the kinds of relationships Prolog can express: Jess offers a rich set of possiblities. Here's one in which the mortality is encoded directly into the facts, so it never needs to be computed at all:
Jess> (deftemplate being (slot name))
Jess> (deftemplate mortal extends being)
Jess> (deftemplate immortal extends being)
Jess> (deftemplate monster extends mortal)
Jess> (deftemplate human extends mortal)
Jess> (deftemplate god extends immortal)
Jess> (defrule list-all-humanoids
;; fire for all beings, gods, monsters, and humans
(being (name ?n))
=>
(printout t ?n " is a being " crlf))
Jess> (defrule list-all-mortals
;; fires only for mortal things
(mortal (name ?n))
=>
(printout t ?n " is mortal " crlf))
Jess> (deffacts beings (human (name Bob)) (monster (name Gollum))
(god (name Zeus)))
Jess> (reset)
Jess> (run)
Zeus is a being
Gollum is mortal
Gollum is a being
Bob is a being
Bob is mortal
5
Here's another that's closer in spirit to the Prolog example.
Jess> (deftemplate thing (slot type) (slot name))
Jess> (deffacts things
(thing (type human) (name Socrates))
(thing (type mineral) (name Slate))
(thing (type vegetable) (name Carrot))
(thing (type dog) (name Rover))
(thing (type human) (name Bob)))
Jess> (deffacts mortality
(mortal human)
(mortal dog))
Jess> (defrule list-all-mortals
;; fires for dogs and humans
(mortal ?type)
(thing (type ?type) (name ?n))
=>
(printout t ?n " is mortal." crlf))
Jess> (reset)
Jess> (run)
Bob is mortal.
Rover is mortal.
Socrates is mortal.
3
There's a fact that expresses that humans are mortal, and one for
each human known. In this example, no extra facts are
generated. Nevertheless, the mortality of Socrates is remembered (in
the Rete network) and may be used to
optimize some later computation.
Note that Rete is an algorithm that explicitly trades space for speed, so Jess' memory usage is not inconsiderable. Jess does contain some commands which will allow you to sacrifice some performance to decrease memory usage. Nevertheless, Jess' memory usage is not ridiculous, and moderate-sized programs will fit easily into Java's default 16M heap.
java -XX:NewSize=16m -Xms32m -Xmx32m jess.Main <scriptfile>
Note that the object nursery is a subset of the Java heap set aside
for recently-allocated objects; the total heap size in this example is
32M, not 48M.
The most important step in developing a Jess application is to choose an architecture from among the almost limitless range of possibilities. One way to organize the possibilities is to list them in increasing order of the amount of Java programming involved.
Your choice can be guided by many factors, but ultimately it will depend on what you feel most comfortable with. Types 4) and 5) are most prevalent in real-world applications.