3.1. Lambda EL Value Expressions

Extending from that, one can name the lambda function in EL for reuse in compound statements, just like you would in a lambda expression in Java SE. Compound lambda expressions can be separated by a semi-colon ( ;
):

A clean way to package logic, providing for a very flexible functional programming paradigm. The backing bean logic above could be conditional based on values pulled in from different sources.

An easy way to introduce lambda support in pre-JDK 8 code-bases, that might not be ready to upgrade.

A powerful tool in using the new Streams/Collections API.

4. Collections API Enhancements

The support for the Collections API in earlier versions of EL were somewhat lacking. EL 3.0 has introduced major API improvements in its support for the Java Collections, and just like the lambda expressions, EL 3.0 provides JDK 8 Streaming support within Java EE 7.

4.1. Dynamic Collections Definition

New in 3.0, we can now dynamically define ad-hoc data structures in EL:

Tip
: A common mistake in textbooks (and even in the official documentation from Oracle
) when defining dynamic maps uses double quotes (“) instead of single quote for the Map key – it’s going to result in an EL compilation error.

4.2. Advanced Collection Operations

With EL3.0, there is support for an advanced query semantics that combines the power of lambda expressions, the new streaming API and SQL-like operations like joins and grouping. We won’t cover these in this article as these are advanced topics. Let’s look at a sample to demonstrate its power:

5. Static Fields and Methods

There was no support for static field, method or Enum access in previous versions of EL. Things have changed.

First we have to manually import the class containing the constants into the EL context. This is ideally done as early as possible. Here we’re doing it in the @PostConstruct
initializer of the JSF managed bean (A ServletContextListener
is also a viable candidate) :

Per the EL 3.0 specification, any class outside of java.lang.*
needs to be manually imported as shown. It’s only after doing this that the constants defined in a class are available in EL. The import is ideally done as part of the initialization of the JSF runtime.

A few notes are necessary here:

The syntax requires that the fields and methods be public, static
(and final
in the case of methods)

The syntax changed between the initial draft of the EL 3.0 specification and the release version. So in some textbooks, you might still find something that looks like:

T(YourClass).yourStaticVariableOrMethod

This won’t work in practice (a design change to simplify the syntax was decided late into the implementation cycle)

6. Conclusion

We’ve examined some of the highlights in the latest EL implementation. Major improvements were made to bring cool new features like lambda and streams flexibility to the API.

With the flexibility that we now have in EL, it’s important to remember one of the design objectives of the JSF framework: clean separation of concerns with the use of the MVC pattern.

So it’s worth noting that the latest improvements to the API may open us up to anti-patterns in JSF, because EL now has the capability to do real business logic – more so than before. And so it’s definitely important to have that in mind during a real-world implementation, to make sure responsibilities are neatly separated.

And of course, the examples from the articles can be found in GitHub
.