Condition Languages

In Jadex the specification languages for rules are different for the left and the right hand side of the rule. For the definition of the conditions (left hand side) three options are available:

• A CLIPS language derivate can be used.
• A proprietary dialect of Java expressions called Java condition language (jcl) can be used.
• Conditions can be created manually by constructing the corresponding Jadex Rules objects directly.

In the following section each of these options is explained in more details.

Note: This document is still under construction and thus partially incomplete.

CLIPS Condition Language

todo:

Java Condition Language (JCL)

The Java Condition Language or JCL for short allows specifying the condition part (left hand side) of a rule in a Java-like language. In essence, a JCL expression is a Java expression that can be evaluated to a boolean value. The subset of Java, which is supported in a JCL expression is described in the next section ('Supported Java Expressions'). But JCL also allows to bind variables to arbitrary objects in the state using so called existential declarations. Additionally, existential declarations can be combined with the Java logical NOT operator ('!') to form non-existence conditions that work like 'not' conditions in CLIPS.

Supported Java Expressions

As a rule of thumb, Java code allowed in the condition of an 'if' statement is also supported by JCL. To be more concrete, you can e.g. use constant literals and variables, as well as operations on these.

Example: $x==3

Here, '$x' is a variable (the prefix '$' is only a convention and not mandatory), '==' is the equality operator and '3' is an integer literal.

The Java language specification (JLS) introduces the term 'primary expression' for basic expression that do not contain operators (see Section 15.8 of the JLS). The following primary expressions are supported in JCL:

• Literals (strings, integers, etc.)
• Constants (i.e. public static final fields. A warning will be printed when a non-final field is accessed, because the rule engine would not be able to track changes to this field.)
• Static methods (again, as the rule engine cannot track internal changes, the result value of static method should only depend on the parameter values, i.e. the method should behave like a function)
• Variables (as rule conditions are evaluated without context, each variable needs to be bound in the expression using a corresponding existential declaration as described below)

The following operators are supported in their normal Java semantics:

• Array index access (e.g. '$myarray[0]')
• Method calls and field access (e.g. '$object.someMethod($para)' or '$object.some_field')
• Type casts (useful for method calls, e.g. '((Map)$object).get("key")')
• Math operators (unary and binary '+' and '-', as well as '*', '/', '%')
• Comparison operators ('==', '!=', '<', '>', '<=', '>=', require that objects correctly implement the equals method resp. the java.lang.Comparable interface)
• Boolean operators ('&&', '||', '!', remember to escape '&&' with '&&' when writing in XML)
• Conditional operator ('$choice ? $option1 : $option2')

The following primary expressions and operators are not yet implemented and will be added in future versions:

• Object creation ('new XYZ()')
• Shift operators ('<<', '>>', '>>>')
• instanceof
• bitwise boolean operators ('&', '|', '^')

The following operators are not supported and never will be, because they have side effects:

• Assignments (e.g. '$a = $b')
• Combined assigments (e.g. '$a += $b')
• Pre- / postfix increment or decrement ('$a++')

Existential Declarations

The basic principle of a rule engine is to find facts in the working memory, that match conditions of the rules. To support the static type system of Java, variables need to be declared in JCL. According to the rule engine principle, a variable declaration requires that an object exists, that can be bound to this variable. Thus the name 'exitential declaration'. The basic form of an existential declaration is also one of the simplest conditions that can be expressed in JCL: '<typename> <variablename>', e.g. 'Block $b'. Thinking of the existential declaration as (part of) a Java expression it should be interpreted as having a boolean return value, e.g. 'Block b$' means "there is some object of type Block", which can be true or false depending on the objects in the state.

Because an existential declaration is like a boolean expression, it can be combined with other expressions using boolean operators. E.g. the expression 'Block $b && $b.color=="red"' states that there is some block and that this block has the color 'red'. As you can see, a variable that is bound in an existential declaration can be used in other parts of the expression.

Using NOT for Existential Declarations

Future Extensions

• collect
• return values!?

Rules API Language

todo: