Package jakarta.servlet.jsp.el

Provides the ELResolver classes that define the object resolution rules that must be supported by a JSP container with the new unified Expression Language.

References in this document to JSP refer to the Jakarta Server Pages unless otherwise noted.

The package also defines programmatic access to the old Expression Language evaluator (pre JSP 2.1).

Please note that as of JSP 2.1, all classes and interfaces that were in package jakarta.servlet.jsp.el have been deprecated in favor of the new unified Expression Language APIs (jakarta.el). See the Expression Language specification document for more details.

While a JSP container must still support the deprecated APIs defined in jakarta.servlet.jsp.el, developers should only rely on the new jakarta.el APIs for new development work.

Two ELResolver classes have been added in JSP 2.1 to implement object resolution rules that must be supported by a JSP container with the new unified Expression Language: ImplicitObjectELResolver and ScopedAttributeELResolver.

Documentation on the old and deprecated API

The Jakarta Server Pages 2.0 specification provides a portable API for evaluating "EL Expressions". As of JSP 2.0, EL expressions can be placed directly in the template text of JSP pages and tag files.

This package contains a number of classes and interfaces that describe and define programmatic access to the Expression Language evaluator. This API can also be used by an implementation of JSP to evaluate the expressions, but other implementations, like open-coding into Java bytecodes, are allowed. This package is intended to have no dependencies on other portions of the JSP 2.0 specification.

Expression Evaluator

Programmatic access to the EL Expression Evaluator is provided through the following types:
  • ExpressionEvaluator
  • Expression
  • FunctionMapper
  • VariableResolver

An ExpressionEvaluator object can be obtained from a JspContext object through the getExpressionEvaluator method. An ExpressionEvaluator encapsulates the EL processor. An EL expression provided as a String can then be evaluated directly, or it can be parsed first into an Expression object. The parse step, can be used to factor out the cost of parsing the expression, or even the cost of optimizing the implementation.

The parsing of an expression string is done against a target type, a default prefix (that applies when a function has no prefix), and a FunctionMapper. The FunctionMapper object maps a prefix and a local name part into a java.lang.reflect.Method object.

The interpretation or evaluation of a parsed expression is done using a VariableResolver object. This object resolves top level object names into Objects. A VariableResolver can be obtained from a JspContext object through the getVariableResolver method.


The ELException exception is used by the expression language to denote any exception that may arise during the parsing or evaluation of an expression. The ELParseException exception is a subclass of ELException that corresponds to parsing errors

Parsing errors are conveyed as exceptions to simplify the API. It is expected that many JSP containers will use additional mechanisms to parse EL expressions and report their errors - a run-time API cannot provide accurate line-error numbers without additional machinery.

Code Fragment

Below is a non-normative code fragment outlining how the APIs can be used.

// Get an instance of an ExpressionEvaluator

ExpressionEvaluator ee = myJspContext.getExpressionEvaluator();
VariableResolver vr = myJspContext.getVariableResolver();

FunctionMapper fm; // we don't have a portable implementation yet

// Example of compiling an expression.  See [ISSUE-2]
// Errors detected this way may have higher quality than those
// found with a simple validate() invocation.

ExpressionCompilation ce;

try {
  ce = ee.prepareExpression(expr,
                            null // no prefixes
} catch (ELParseException e) {
        log (e.getMessage());

try {
} catch (ElException e) {
        log (e);