It should be noted that one could write a builder by implementing the de.odysseus.el.tree.TreeBuilder interface from scratch. However, you may also want to subclass the Builder class and override the createParser() to work with a modified parser implementation.

Either way, the new tree builder can be passed to a factory via

TreeStore store = new TreeStore(new MyBuilder(), new Cache(100));
ExpressionFactory factory = new ExpressionFactoryImpl(store);

As an alternative, you may set property

de.odysseus.el.tree.TreeBuilder

to the fully qualified class name of your builder implementation.

Many people have noticed the lack of method invocations as a major weakness of the unified expression language. When talking about method invocations, we mean expressions like ${foo.matches('[0-9]+')} that aren't supported by the 2.1 standard. However, method invocations have been added in maintenance release 2 of JSR 245, which is supported by JUEL.

To enable (disable) expressions using method invocations, you may set property

javax.el.methodInvocations

to true (false).

Method invocations are enabled in profile JEE6 (default) and disabled in JEE5.

The EL specification does not support function calls with variable argument lists. That is, if we bind String.format(String, Object...) to function str:format, the expression ${str:format('Hey %s','Joe')} will not work.

To enable (disable) VarArgs in function and method invocations, you may set property

javax.el.varArgs

to true (false).

VarArg invocations are enabled in profile JEE6 (default) and disabled in JEE5.

The EL specification describes the evaluation semantics of base[property]. If property is null, the specification states not to resolve null on base. Rather, null should be returned if getValue(...) has been called and a PropertyNotFoundException should be thrown else. As a consequence, it is impossible to resolve null as a key in a map. However, JUEL's expression factory may be configured to resolve null like any other property value.

To enable (disable) null as an EL property value, you may set property

javax.el.nullProperties

to true (false).

Assume that identifier map resolves to a java.util.Map.

• If feature javax.el.nullProperties has been disabled, evaluating ${base[null]} as an rvalue (lvalue) will return null (throw an exception).
• If feature javax.el.nullProperties has been enabled, evaluating ${base[null]} as an rvalue (lvalue) will get (put) the value for key null in that map.

The default is not to allow null as an EL property value.

The EL specification allows to determine an expected return type for method expressions. The return type should then be checked to match the actual return type of the method to invoke. Unfortunately, the EL reference implementation ignores this parameter completely. This caused some "legacy" code to not recognize that they're passing wrong types. When switching to JUEL as their EL implementation, this causes an exception to be thrown.

For compatibility, JUEL lets you choose to ignore the expected return type passed to EpressionFactory.createMethodExpression() when looking up a method to invoke. (This option has no effect when evaluating literal method expressions, where the expected return type acts as coercion target type.)

To enable (disable) ignoring of the expected return type parameter, you may set property

javax.el.ignoreReturnType

to true (false).

The default is respect (i.e. not to ignore) the expected return type parameter.

The default lru cache implementation can be customized by specifying a maximum cache size. However, it might be desired to use a different caching mechanism. Doing this means to provide a class that implements the TreeCache interface.

Now, having a new cache implementatation, it can be passed to a factoy via

TreeStore store = new TreeStore(new Builder(), new MyCache());
ExpressionFactory factory = new ExpressionFactoryImpl(store);

As for all objects, the equals(Object) method is used to test for equality. The specification notes that two expressions of the same type are equal if and only if they have an identical parsed representation.

This makes clear, that the expression string cannot serve as a sufficient condition for equality testing. Consider expression string ${foo}. When creating tree expressions from that string using different variable mappings for foo, these expressions must not be considered equal. Similar, an expression string using function invocations may be used to create tree expressions with different function mappings. Even worse, ${foo()} and ${bar()} may be equal if foo and bar referred to the same method at creation time.

To handle these requirements, JUEL separates the variable and function bindings from the pure parse tree. The tree only depends on the expression string and can therefore be reused by all expressions created from a string. The bindings are then created from the tree, variable mapper and function mapper. Together, the tree and bindings form the core of a tree expression.

When comparing tree expressions, the trees are structurally compared, ignoring the names of functions and variables. Instead, the corresponding methods and value expressions bound to them are compared.

As required by the specification, all expressions have to be serializable. When serializing a tree expression, the expression string is serialized, not the tree. On deserialization, the tree is rebuilt from the expression string.