JUEL is an implementation of the Unified Expression Language (EL), specified as part of the JSP 2.1 standard (JSR-245), which was introduced in JEE5. Additionally, JUEL 2.2 implements the JSP 2.2 maintenance release specification for full JEE6 compliance.

JUEL provides a lightweight and efficient implementation of the Unified Expression Language.

• High Performance – Parsing expressions is certainly the expected performance bottleneck. JUEL uses a hand-coded parser which is up to 10 times faster than the previously used (javacc) generated parser! Once built, expression trees are evaluated at highest speed.
• Pluggable Cache – Even if JUELs parser is fast, parsing expressions is relative expensive. Therefore, it's best to parse an expression string only once. JUEL provides a default caching mechanism which should be sufficient in most cases. However, JUEL allows to plug in your own cache easily.
• Small Footprint – JUEL has been carefully designed to minimize memory usage as well as code size.
• Method Invocations – JUEL supports method invocations as in ${foo.matches('[0-9]+')}. Methods are resolved and invoked using the EL's resolver mechanism. As of JUEL 2.2, method invocations are enabled by default.
• VarArg Calls – JUEL supports Java 5 VarArgs in function and method invocations. E.g., binding String.format(String, String...) to function format allows for ${format('Hey %s','Joe')}. As of JUEL 2.2, VarArgs are enabled by default.
• Pluggable – JUEL can be configured to be transparently detected as EL implementation by a Java runtime environment or JEE application server. Using JUEL does not require an application to explicitly reference any of the JUEL specific implementation classes.

• Axional Studio, takes advance of JUEL on all expressions labeled as JUEL, and many other parts like the package [vtable.matches] of the SQL Script

• Axional Terminal, does also use JUEL to evaluate field expressions

You can use the following operators, which can be used in rvalue expressions only

• Arithmetic: +, - (binary), *, / and div, % and mod, - (unary)
• Logical: and, &&, or, ||, not, !
• Relational: ==, eq, !=, ne, <, lt, >, gt, <=, ge, >=, le. Comparisons can be made against other values or against Boolean, string, integer, or floating-point literals.
• Empty: The empty operator is a prefix operation that can be used to determine whether a value is null or empty.
• Conditional: A ? B : C. Evaluate B or C, depending on the result of the evaluation of A.

The precedence of operators highest to lowest, left to right is as follows:

• () (used to change the precedence of operators)
• - (unary) not ! empty
• * / div % mod
• + - (binary)
• < > <= >= lt gt le ge
• == != eq ne
• && and
• || or
• ? :

The following words are reserved for the EL and thus, they should not be used as identifiers:

JUEL is an implementation of the Unified Expression Language (EL), specified as part of the JSP 2.1 standard (JSR-245).

The following tables show a list of expressions.

EL can access object as beans. For example, with a variable of type date you can access the date methods directly.

Suposse you have the variable date with Sat Oct 20 00:00:00 CEST 2012

• date.day will return 20
• date.month will return 9 (not 10 for October as Java starts counting months at 0)
• date.year will return 2012

A special set of extensions is included to add functions that are present in SQL languages.

IN operator to search if a string is within a list of strings

'a' IN ('a', 'b', 'c', 'd')

true

MATCHES operator to match a string in a pattern

'abab' MATCHES '(ab)*'

true

'abab' MATCHES '(ba)*'

false

Functions are referenced using a prefix and a local name and they should be referenced via prefix:localname. A set of functions is intrinsically declared.

Special care should be applied when handling nulls.

• A null value is not an empty string
• A variable with value null still is an existing variable and can be used for comparison

The following table shows comparison of a string with null

The following table shows arithmetics with null or strings

In some cases, you may need to properly convert numbers to appropiate type before operating. A set of conversion funcions is provided for your convenience.

Depending numeric types, Java will generate Infinity or ArithmeticException when divide by 0.

• In case of double/float division, the output is Infinity, the basic reason behind that it implements the floating point arithmetic algorithm which specifies a special values like “Not a number” OR “infinity” for “divided by zero cases” as per IEEE 754 standards.
• In case of integer or BigDecimal division, it throws ArithmeticException. This is the major case cause eval on integers uses always double precision numbers.

• BigDecimal division by 0 returns null cause BigDecimal can not represent Infinity.
• Other numeric division by 0 returns Infinity or Nan (as double precision arithmetic is used even for integers).

As seen before, division by zero using a double returns NaN.

NaN is by definition not equal to any number including NaN. This is part of the IEEE 754 standard and implemented by the CPU/FPU. It is not something the JVM has to add any logic to support.

This produces the following results

public static void main(String a[]) {
    System.out.println(Double.NaN==Double.NaN);
    System.out.println(Double.NaN!=Double.NaN);
}

false
true

So, to compare for a NaN you should use the Double.isNan(double) function.

In Java financial programming, you need the precision BigDecimals afford. However, due to the great precision of this value, comparisons are very error prone.

For example:

0.000000000000000000000000000000001 != 0.0

For most cases, we want to round when the calculations are complete to the desired precision, rather than during intermediate steps.

For BigDecimals equals checks both value and scale giving different results when comparing numbers with different scales.

When variables come from BigDecimal numbers, comparison with constant values or other numeric variables may be affected by scaling. Lets see the following EL examples.

As explained before, a BigDecimal division by 0 results in ArithmeticException. To prevent that, and the need of manually fix all expressions, the coerce function returns a BigDecimalWrapper that prevents ArithmeticException.

The BigDecimalWrapper divide function returns null when the divisor is 0.

The UEL expression is available in some wic_jrep_object expressions. In this context, special functions are available in order to expose and pass the Object information. The available functions are:

• adapter: This retrieves data belonging to the current row of the adapter.
• parent: This gets the data belonging to the current row of the parent adapter.
• variable: Data comes from variables defined as input of the object. (wic_jrep_colvar)
• field: Data from field buttons and SQL catalogued. It is only available to retrieve data belonging to the statement of the buttons (wic_jrep_form_butt) or the catalogued SQL (wic_jrep_form_query).

Notice that if no modifier is prefixed then the variable asumes the value of the most proper source of result data.

Functions can be invoked directly:

adapter('estcab') != 'E'

parent('estcab') != 'E'

variable('fecini') > date:parse('dd-MM-yyyy', '20-10-2012')

field('fecini') > date:parse('dd-MM-yyyy', '20-10-2012')

fecini > date:parse('dd-MM-yyyy', '20-10-2012')

In some cases, UEL expressions are used inside statement expressions, using the syntax ${expr}. The mentioned functions are also available on those expressions:

<call name='myxsqlscript'>
    <args>
        <arg>${adapter('cabid')}</arg>
        <arg>${variable('fecini')}</arg>
        <arg>${field('copycrc')}</arg>
    </args>
</call>