1. Introduction

1.1. Compatibility

Jess is compatible with all versions of Java starting with Java 1.1. In particular, this includes JDK 1.2 (or "Java 2" as it is now known.) All versions of Jess later than version 4.x are no longer compatible with Java 1.0.

1.2. Mailing List

There is a Jess email discussion list you can join. To get information about the jess-users list, send a message to majordomo@sandia.gov containing the text
  help
  info jess-users
  end
as the body of the message. There is an archive of the list at http://www.mail-archive.com/jess-users@sandia.gov .

1.3. Bugs

This is the first beta release of Jess 5.0. There are probably bugs. Please report any that you find to me at ejfried@ca.sandia.gov so I can fix them for a later release.

1.4. Assumptions

Jess is a programmer's library. The library itself is written in Java. The library serves as an interpreter for another language, which I will refer to in this document as the Jess language. The Jess language is very similar to the language defined by the CLIPS expert system shell, which in turn is a highly specialized form of LISP.

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 If you do not have at least this passing familiarity with a Java environment, then may I suggest you purchase an introductory book on the topic.

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 tagreted 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.

1.5. Getting ready

1.5.1. Unpacking the Distribution

If you download Jess for UNIX, you can extract the files using tar and uncompress:
        uncompress Jess-5.0b1.tar.Z
        tar xf Jess-5.0b1.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 Jess50b1/. Inside this directory should be the following files and subdirectories:

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.
jess/awt Java source which help you to create Java GUIs directly from Jess.
examples/ A directory of tiny example Jess files.
jess/examples A directory of more complicated examples, containing example Java source files.
Makefile A simple makefile for Jess.

1.5.2. Compiling Jess

Jess comes as a set of Java source files. You'll need to compile them first. If you have a make utility (any UNIX-like make; you could use the CygWin environment on Windows), you can just run make and the enclosed makefile will build everything. You might have to edit it a bit first. Otherwise the command:
  javac -d . jess/*.java jess/awt/*.java
would work just fine, given that you have a Java compiler named javac (as in Sun's JDK) and that Jess50b1/ 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 Jess50b1/jess/ directory; it won't work. You must use a Java 1.1 or later compiler to compile Jess. The resulting code will run on a Java 1.1 or later VM. Jess works great with Java 1.2.

There are a number of optional example source files in the subdirectories Jess50b1/jess/examples/ that aren't compiled if you follow the instructions above. You can issue a command like:
  javac -d . jess/examples/*/*.java

Again, don't set your current directory to, for example, Jess50b1/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 Jess50b1 directory. I can't stress this enough: this is by far the most common problem people have in getting started with Jess!

I personally use the Jikes Java compiler from IBM. The compiler itself is very fast (compiles all of Jess in just a few seconds on my machine!) I highly recommend it, and it's free!

1.5.3. Jess Example Programs

There are a few trivial example programs (in the examples/ directory) that you can try to confirm that you have properly compiled Jess. including fullmab.clp, zebra.clp, and wordgame.clp. fullmab.clp is a version of the classic Monkey and Bananas problem. To run it yourself from the command line, just type:
  java jess.Main examples/fullmab.clp
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 huge 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.

1.5.4. Command-line Interface

Jess has an interactive command-line interface. Just type java jess.Main to get a Jess> prompt. To execute a file of CLIPS code from the command prompt, use the batch command:
 
  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 in bold. 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 editor named notepad on your system, try:
  Jess> (system notepad README &)
  TRUE
The & character makes the editor run in the background. Omitting it will keep the system command from returning until the called program exits.

The class jess.Console is a graphical verison of the Jess command-line interface. You type into atext field at the bottom of the window, and Output appears in a scrolling window above. Type java jess.Console to try it.

1.5.5. Jess as an Applet

The class jess.ConsoleApplet is a generic Jess applet that uses the same display as the jess.Console class. It can be used in general question-and-answer situations simply by embedding the applet class on a Web page. The applet accepts two applet parameters. The value of an INPUT parameter will be interpreted as a Jess program to run when starting up. Note that when this program halts, the Jess prompt will appear in the applet window. The applet also accept a COMPACT parameter. If present, ConsoleApplet will contain only a bare-bones version of Jess (no optional functions will be loaded).

Note that the ConsoleApplet and ConsoleDisplay classes now use the Java 1.1 event model, which is still not supported by much of the installed base of Web browsers. Don't use them 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.

1.6. What makes a good Jess application?

Jess can be used in two overlapping ways. First, it can be a rule engine - a special kind of program that very efficiently applies rules to data. A rule-based program can have hundreds or even thousands of rules , and Jess will continually apply them to data in the form of a knowledge base . Often the rules will represent the heuristic knowledge of a human expert in some domain, and the knowledge base will represent the state of an evolving situation (an interview, an emergency). In this case, they are said to constitute an expert system. Expert systems are widely used in many domains. Among the newest applications of expert systems are as the reasoning part of intelligent agents, in enterprise resource planning (ERP) systems, and in order validation for electronic commerce.

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.)

1.7. About Jess and performance

Jess's rule engine uses an improved form of a well-known algorithm called Rete (latin for "net") to match rules against the knowledge base. Jess is actually faster than some popular expert system shells written in C, especially on large problems, where performance is dominated by algorithm quality.

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.

1.8. Command-line, GUI, or embedded?

As we've discussed, Jess can be used in many ways. Besides the different categories of problems Jess can be applied to, being a library, it is amenable to being used in many different kinds of Java programs. Jess can be used in command-line applications, GUI applications, servlets, and applets. Furthermore, Jess can either provide the Java main() for your program, of you can write it yourself. You can develop Jess applications (with or without GUIs) without compiling a single line of Java code. You can also write Jess applications which are controlled entirely by Java code you write, with a minumum of Jess language code.

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.
  1. Pure Jess language scripts. No Java code at all.
  2. Pure Jess language scripts, but the scripts access Java APIs.
  3. Mostly Jess language scripts, but some custom Java code in the form of new Jess commands written in Java.
  4. Half Jess language scripts, with a substantial amount of Java code providing custom commands and APIs; main() provided by Jess.
  5. Half Jess language scripts, with a substantial amount of Java code providing custom commands and APIs; main() written by you.
  6. Mostly Java code, which loads Jess language scripts at runtime.
  7. All Java code, which maniulates Jess entirely through its Java API. This option is not fully supported at this time, but hopefully will be by the Jess 5.0 final release.
Examples of some of these types of applications are package with Jess. The basic examples like wordgame.clp, zebra.clp, and fullmab.clp are all type 1) programs. draw.clp and frame.clp are type 2) programs. The pumps example is packaged two ways. If you run it using the script file pumps.clp, it is a type 4) program; if you run it using MainInJava.java, it is a type 6) application.

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.