EL Static Access, Records & Optional

The view below uses the java.lang classes Boolean, Integer and Math with no import, and the Bookshelf class Shelf after a page directive import. Static methods take arguments in the normal way, and they can take beans from the page: ${Shelf.describe(book)} passes the Book request attribute to a static method.

Source: Jakarta Expression Language 6.0 — 1.24 Static Field and Method Reference

Source: Jakarta Pages 4.0 — 1.10.1 The page Directive

The EL on its own imports java.lang.* only. The specification lets a technology that uses EL add more, and Pages does: the import attribute of the page directive (see the Directives page) describes "the types that are available to the scripting and EL environments", and the container implicitly imports java.lang.*, jakarta.servlet.*, jakarta.servlet.jsp.* and jakarta.servlet.http.*. That the EL environment has the same defaults as the scripting environment was clarified in Pages 3.1. A page can add more with import, as it does for Shelf above, and can import a whole package or a single class.

The import handler is the object ELContext.getImportHandler() returns, and PageContext.getELContext() gives a page its ELContext. A page without Java code cannot reach that object, so the place to add imports at run time is an ELContextListener registered with JspApplicationContext.addELContextListener: the container calls its contextCreated method for every ELContext it creates for a page, and the listener adds its imports through the ImportHandler of the new context. The listener is registered once, from a ServletContextListener, and applies to every page of the application:

Source: Jakarta Pages 4.0 Javadoc — JspApplicationContext.addELContextListener

Source: Jakarta Expression Language 6.0 Javadoc — ELContextListener

The next view shows the three styles in one page: a package import (java.time.*), a class import (java.math.RoundingMode, org.example.bookshelf.Status) and the two static imports made by the listener.

Source: Jakarta Expression Language 6.0 — 1.24.2 Imports of Packages, Classes, and Static Fields

Source: Jakarta Expression Language 6.0 Javadoc — ImportHandler

Legacy alternative: older pages made the same static imports for one page only, from a scriptlet at the top of the page, pageContext.getELContext().getImportHandler().importStatic("java.lang.Math.max"). It gives the same output but puts Java code in the view, which the rest of this section avoids; prefer the listener, or a tag handler when the imports belong to one page.

Source: Jakarta Pages 4.0 Javadoc — JspContext.getELContext

Source: Jakarta Expression Language 6.0 — 1.24.4 Additional Default Imports

Two things in that output are worth stating. A static import (importStatic) of a static method makes the name usable without its class, which is why ${max(3, 7)} works with no class. And the page-level import is per page: the import handler belongs to the page’s ELContext, so a class imported in one page is not known to a page that it includes dynamically. The include directive is different, because it merges the source of the included file into the including page before translation, so the imports apply to it. The next view includes the same fragment both ways.

The jsp:include copy runs as a separate page, so Shelf is unknown there and prints nothing; the include directive copy sees the import. The Includes, Forwards and Page Composition page treats the two mechanisms in full.

Source: Jakarta Pages 4.0 — 1.10.2 The include Directive

A class name followed by arguments in parentheses calls the constructor, under the same rules as a static method: the class must be public, concrete and already imported. ${Boolean(true)} is the specification’s own example.

Source: Jakarta Expression Language 6.0 — 1.24.3 Constructor Reference

The default imports are a convenience for page authors and a hazard for everything else. java.lang contains Runtime, System, Thread and ProcessBuilder, and the Pages packages contain Cookie, so an expression that an attacker can choose is not limited to reading the Bookshelf. The next page prints only harmless values, which is the point: the reach is there, and it is the reason this section never builds an expression from request input.

Source: Jakarta Pages 4.0 — 1.10.1 The page Directive (import)

Three rules follow from the output.

Each of the three pages below fails or prints nothing on purpose; every message is quoted from the response.

The third row is the dangerous one: the comparison ${book.status == Status.AVAILABLE} is quietly false for every book when the Status import is missing, because Status is null. A page that shows a "Borrow" button only when the status equals the constant would hide it for everybody, with no log line.

Source: Jakarta Pages 4.0 — 2.7 Unknown EL Identifiers

Because the record resolver looks only for the component accessor, every property is a component name, and nothing else counts. The three failures below were reproduced, each on its own page.

Source: Jakarta Expression Language 6.0 Javadoc — RecordELResolver (getValue, setValue)

Source: Jakarta Standard Tag Library 3.0 — c:set

Records also fit the rest of the platform: they are a good shape for a read-only view model that a servlet builds and a JSP prints, and the Java side of the language feature is on the Records and Sealed Classes page, with Enums for the enum side. Form binding is the opposite case: a record has no setters, so a framework that binds request parameters by calling setters on a bean (see Forms, Validation and Sessions, Spring MVC with JSP and the Struts parameter injection page) needs a mutable class or a framework that constructs records.

Without any registration, a java.util.Optional is printed with its toString(), is never null, is never empty, and exposes only its own methods. This is the output of the plain WAR (g4elstatic, no resolver):

Source: Jakarta Expression Language 6.0 — 1.23 java.util.Optional (default behaviour)

Three lines deserve a second look. The empty ISBN is printed as Optional.empty and not as nothing. ${empty noIsbn.isbn} is false, and c:if with not empty therefore takes the "has isbn" branch for a book with no ISBN. To test for presence without the resolver, call the method: ${noIsbn.isbn.isPresent()}, shown next.

Navigating through the Optional does not work. The rawOptional attribute is an Optional<Book>:

curl http://localhost:18080/g4elstatic/view/optional-nav returns HTTP 500 with jakarta.el.PropertyNotFoundException: Property [title] not found on type [java.util.Optional], which is exactly the failure the specification describes for someObject.optionalProperty.otherProperty.

Source: Jakarta Expression Language 6.0 — 1.23 java.util.Optional

The methods of the Optional itself are called like any other method:

On the plain WAR these three return [true], [n/a] and [978-0-06-051275-0].

Source: Java SE 21 — java.util.Optional.orElse

OptionalELResolver is a normal ELResolver, so it is registered the way any application resolver is: through the JspApplicationContext of the web application, which Pages 4.0 section 2.10 places right after the implicit objects in the chain. The natural place is a ServletContextListener; the one below reads a context parameter so the same code ran as the plain WAR (false) and the Optional-enabled WAR (true).

Source: Jakarta Pages 4.0 Javadoc — JspApplicationContext.addELResolver

Source: Jakarta Pages 4.0 Javadoc — JspFactory.getJspApplicationContext

Source: Jakarta Expression Language 6.0 Javadoc — OptionalELResolver

The registration is application-wide and happens once, at start-up. After it the chain looks through every java.util.Optional in every page of the application: this is a global change of semantics that cannot be limited to one page, so every page that calls .isPresent() or .orElse(...) breaks (below). The Javadoc defines the behaviour precisely: for an Optional base, an empty Optional resolves every property to null; a populated one resolves the property on its content, by calling the whole resolver chain with the content as the base; with a null property the content itself is the value; method calls are forwarded to the content, and an empty Optional answers null to every method call; and coercion to a type is done on the content, or on null when empty.

Source: Jakarta Expression Language 6.0 Javadoc — OptionalELResolver.getValue

Source: Jakarta Expression Language 6.0 Javadoc — OptionalELResolver.invoke

The Optional-enabled outputs, side by side with the plain ones above:

Three of the rows deserve a sentence each. The empty operator is not touched by the resolver: an Optional is never empty and never null as far as empty and == against null are concerned, even though it prints as nothing and compares equal to its content. A c:if on not empty book.isbn is therefore true for every book. The orElse row is a silent change of meaning: the same expression returns the default on the plain WAR and an empty string on the Optional-enabled one, with no error. And the two method rows show that with the resolver, the Optional’s own API is unreachable.

The pattern that works with and without the resolver, and that does not tie the pages to a global switch, is to unwrap in the servlet or in the view model. Put the nullable value in the request (book.isbn().orElse(null)), or add a component of a plain type to the view record, and let the page use the ordinary EL null handling, empty, c:if and c:out default. Reach for the resolver only in an application that has chosen to model its optional properties as Optional and to read them with property syntax everywhere, so that no page calls an Optional method. In that case register it once, in a listener, and never mix the two styles, as the table above shows why.

A terminal operation on an EL stream returns EL’s own Optional, with four methods: get() (an ELException if empty), ifPresent, orElse and orElseGet. It is independent of the resolver: the same pages behave the same on both WARs.

Calling get() on an empty one fails (err-optional-get.jsp, the expression ${books.stream().filter(b -> b.year > 2100).findFirst().get()}): HTTP 500 with jakarta.el.ELException: It is illegal to call get() on an empty optional. There is no isPresent() on the EL class, so the test for emptiness is orElse with a default, or orElseGet. The lambdas and the stream operations themselves are on the Lambdas, Collections and Streams page; the Java language side is on the Optional, Lambdas and Method References and Streams and Collectors pages.

Source: Jakarta Expression Language 6.0 — 2.3.3.2 Optional (get, ifPresent, orElse, orElseGet)