13. Release Notes

• The unique CE has been removed. For the time being, the parser will accept but ignore it. If your program depended on unique for correct operation, it may need to be rewritten. Note that the manual has always discouraged use of unique for anything other than optimization.
• The assert method in the Rete class is deprecated; use Rete.assertFact() instead. assert will be removed in the first post-6.1 release.
• Nested conditional elements. Jess 6.1 supports full, arbitrary, and correct nesting of and, or, and not conditional elements.
• logical facility Java interface. There is now a public Java API (in the jess.Rete class) to the logical dependency facility. There are also two Jess functions, dependencies and dependents, that give you logical information about a specific fact.
• updateObject method. You can call jess.Rete.updateObject() to notify Jess that the properties of a static definstance have changed.

• Java 2 is required. Jess 6 now requires a Java 2 compatible JVM (JDK 1.2 or later.) Jess 5 worked with JDK 1.1.
• Batch files in JAR files. The rules for loading a batch file from a JAR have changed. See the javadoc for java.lang.Class.getResource() for the appropriate way to reference a batch file in a JAR.
• Strategy interface changed. If you wrote any custom conflict resolution strategies for Jess 5, they need to be rewritten from scratch for Jess 6.
• No functions are optional. Under Jess 5, you had to load a number of optional Userpackages using Rete.loadPackage(). In Jess 6, there are -no- optional functions; everything is loaded by default. Loading packages redundantly does no harm, it's just inefficient. More seriously, some of the old optional packages either no longer exist, or no longer support the Userpackage interface. Simply delete any code you have in your app which calls Rete.addUserpackage() on a Jess-supplied package. In Jess 6.1, these classes are no longer public.
• Script library loaded automatically. Under Jess 5, you had to load the Jess script library manually; in Jess 6, it happens automatically. There's no harm in loading it redundantly, but there's no value in it, either.
• Pattern bindings are jess.Fact objects. Perhaps the biggest change is that pattern bindings, like ?var in

                          ?var <- (pattern)
                      

  are jess.Fact objects in Jess 6, not just integers as they were in Jess 5. That means that Jess 5 code like

                          ;; Get the 'head' of a fact
                          (get (call (engine) findFactById ?var) name)
                      

  won't work. Instead, it can be replaced by the much simpler and much more efficient

                          ;; Get the 'head' of a fact
                          (get ?var name)
                      

  Some fairly widely distributed code needs to be updated in this way.

• breadth conflict resolution strategy. Both built-in conflict-resolution strategies are now correct under all circumstances. Recall that the order of firing of rules activated by the same fact, with the same salience, is arbitrary. You may now also notice slight differences in this arbitrary ordering compared to previous versions of Jess.
• Backwards chaining during run-query You can now control how many rules can be fired during The run-query using the max-background-rules declaration.
• Performance issues The performance issues with earlier 6.1 alpha versions of Jess have been fixed. Jess 6.1 is faster than Jess 6.0 on many problems.
• Classloader issues The Jess library now works perfectly if you install jess.jar as a standard extension under Java 2. You must use the "app object" constructor for the Rete class if you want Jess to be able to use reflection to manipulate classes from your class path. The classes jess.Main and jess.Console will work if you've installed them this way, but they won't be able to see any classes loaded via your classpath. This is an ongoing issue.
  The "app object" constructor now tells Jess only where to load user classes; it always loads its own scripts and classes from the class loader that loads jess.Rete.
  The manual doesn't yet mention any of this class loader stuff.
• Defclass and Deftemplate inheritance defclass and deftemplate constructs can inherit from each other to the extent that this makes sense.

Back to index