EE6 wishlist part III: Unified EL

Posted by    |       Java EE

This is the third installment of a series. Parts II is here:

The new Unified EL API used by JSF and JSP is a really useful addition to the Java platform. Unfortunately, while a lot of effort was put into designing the Java-level APIs for working with Unified EL, the expression language itself hasn't changed much since the earliest days of JSP. It is now well past time for some new features. A more powerful EL lets us keep presentation logic in our page, and avoids polluting the business model with extra methods.

Here's some suggestions I have, though I'm not at all attached to the suggested syntaxes.

Method parameters

This is one of those what were they thinking?! moments. Unified EL does not support method expressions with parameters. Really.

Suggested syntax:


Switch statement

In JSP or JSF pages it's very useful to be able to handle multiple cases in a single expression.

Suggested syntax:

switch (order.status) { case OPEN: 'Open' case CLOSED: 'Closed' else '' }

Dates and times

Currently, there is no way to compare dates and times in EL. The <, >, <= and >= operators should be extended to support java.util.Date. It may also be worth introducing a syntax for date/time literals.

Collection size operator

Amazingly, there is no simple way to determine the size of a collection in EL!

Suggested syntax:

size customer.orders 

This operator should work for any Collection, Map, String or Iterable. Furthermore, the empty operator should be extended to support Map and Iterable.

Collection constructors

When defining pages, it is useful to be able to iterate over collection literals.

Suggested syntax for creating a java.util.List instance:

{'foo', 'bar', 'baz'}

Suggested syntax for creating a java.util.Map instance:

{'foo'->1, 'bar'->3}

Suggested syntax for creating a java.util.List instance with for a specified range of integers:


Collection iteration

This feature is a kind of poor-man's closure support. It should work for all instances of Iterable.

The following suggested syntax returns the list {2, 3, 4}:

{1, 2, 3} collect { x -> x+1 }

The following returns {2, 3}:

{1, 2, 3} select { x -> x>1 }

The following returns the object 2:

{1, 2, 3} detect { x -> x>1 }

The following returns the object 3:

{1, 2, 3} detect { max, x -> max>=x }

The following returns {3, 2, 1}:

{1, 2, 3} desc

The following sorts the customers by name:

customers asc { c -> }

An alternative approach might be to copy Python's list comprehensions:

[ x+1 for x in {1, 2, 3} where x>1 ]

which results in {3, 4}.


The point of this is not to turn Unified EL into a programming language. I actually prefer it to be relatively bare-boned compared to OGNL or MVEL. Rather, the point is to remove certainl pain-points where the only current solution is to fall back to writing presentation logic in Java code.

An alternative to improving the Unified EL would be to allow JSF/JSP expressions to be writting in JavaScript, Groovy, or some other scripting language. I'm openminding on that, it would certainly be possible to wrap the JavaScript interpreter behind a Unified EL ExpressionFactory. But I worry that it pushes people in the wrong direction of writing templates that contain procedural code. The last thing I want to see is JSF templates that look like .rhtml files ;-)

Back to top