The Java EE 5 Tutorial

Unified Expression Language

The primary new feature of JSP 2.1 is the unified expression language (unified EL),
which represents a union of the expression language offered by JSP 2.0 and
the expression language created for JavaServer Faces technology (see Chapter 10, JavaServer Faces Technology) version 1.0.

The expression language introduced in JSP 2.0 allows page authors to use simple
expressions to dynamically read data from JavaBeans components. For example, the test attribute
of the following conditional tag is supplied with an EL expression that compares
the number of items in the session-scoped bean named cart with 0.

<c:if test="${sessionScope.cart.numberOfItems > 0}">
...
</c:if>

As explained in The Life Cycle of a JSP Page, JSP supports a simple request/response life cycle, during which
a page is executed and the HTML markup is rendered immediately. Therefore, the
simple, read-only expression language offered by JSP 2.0 was well suited to the
needs of JSP applications.

JavaServer Faces technology, on the other hand, features a multiphase life cycle designed to
support its sophisticated UI component model, which allows for converting and validating component
data, propagating component data to objects, and handling component events. To facilitate these
functions, JavaServer Faces technology introduced its own expression language that included the following functionality:

These two expression languages have been unified for a couple reasons. One reason
is so that page authors can mix JSP content with JavaServer Faces tags
without worrying about conflicts caused by the different life cycles these technologies support.
Another reason is so that other JSP-based technologies could make use of the
additional features similarly to the way JavaServer Faces technology uses them. In fact,
although the standard JSP tags and static content continue to use only those
features present in JSP 2.0, authors of JSP custom tags can create tags
that take advantage of the new set of features in the unified expression
language.

To summarize, the new, unified expression language allows page authors to use simple
expressions to perform the following tasks:

Dynamically write data, such as user input into forms, to JavaBeans components

Invoke arbitrary static and public methods

Dynamically perform arithmetic operations

The unified EL also allows custom tag developers to specify which of the
following kinds of expressions that a custom tag attribute will accept:

Immediate evaluation expressions or deferred evaluation expressions. An immediate evaluation expression is evaluated immediately by the JSP engine. A deferred evaluation expression can be evaluated later by the underlying technology using the expression language.

Rvalue expression or Lvalue expression. An rvalue expression can only read a value, whereas an lvalue expression can both read and write that value to an external object.

Finally, the unified EL also provides a pluggable API for resolving expressions so
that application developers can implement their own resolvers that can handle expressions not
already supported by the unified EL.

This section gives an overview of the unified expression language features by explaining
the following topics:

Immediate and Deferred Evaluation Syntax

The unified EL supports both immediate and deferred evaluation of expressions. Immediate evaluation means
that the JSP engine evaluates the expression and returns the result immediately when
the page is first rendered. Deferred evaluation means that the technology using the expression language
can employ its own machinery to evaluate the expression sometime later during the
page’s life cycle, whenever it is appropriate to do so.

Those expressions that are evaluated immediately use the ${} syntax, which was introduced
with the JSP 2.0 expression language. Expressions whose evaluation is deferred use the
#{} syntax, which was introduced by JavaServer Faces technology.

Because of its multiphase life cycle, JavaServer Faces technology uses deferred evaluation expressions.
During the life cycle, component events are handled, data is validated, and other
tasks are performed, all done in a particular order. Therefore, it must defer
evaluation of expressions until the appropriate point in the life cycle.

Other technologies using the unified EL might have different reasons for using deferred
expressions.

Immediate Evaluation

All expressions using the ${} syntax are evaluated immediately. These expressions can only
be used within template text or as the value of a JSP tag
attribute that can accept runtime expressions.

The following example shows a tag whose value attribute references an immediate evaluation
expression that gets the total price from the session-scoped bean named cart:

<fmt:formatNumber value="${sessionScope.cart.total}"/>

The JSP engine evaluates the expression, ${sessionScope.cart.total}, converts it, and passes the
returned value to the tag handler.

Immediate evaluation expressions are always read-only value expressions. The expression shown above can
only get the total price from the cart bean; it cannot set the
total price.

Deferred Evaluation

Deferred evaluation expressions take the form #{expr} and can be evaluated at other
phases of a page life cycle as defined by whatever technology is using
the expression. In the case of JavaServer Faces technology, its controller can evaluate
the expression at different phases of the life cycle depending on how the
expression is being used in the page.

The following example shows a JavaServer Faces inputText tag, which represents a text
field component into which a user enters a value. The inputText tag’s value
attribute references a deferred evaluation expression that points to the name property of the
customer bean.

<h:inputText id="name" value="#{customer.name}" />

For an initial request of the page containing this tag, the JavaServer Faces
implementation evaluates the #{customer.name} expression during the render response phase of the life
cycle. During this phase, the expression merely accesses the value of name from
the customer bean, as is done in immediate evaluation.

For a postback, the JavaServer Faces implementation evaluates the expression at different phases
of the life cycle, during which the value is retrieved from the request,
validated, and propagated to the customer bean.

As shown in this example, deferred evaluation expressions can be value expressions that
can be used to both read and write data. They can also
be method expressions. Value expressions (both immediate and deferred) and method expressions are explained
in the next section.

Value and Method Expressions

The unified EL defines two kinds of expressions: value expressions and method expressions.
Value expressions can either yield a value or set a value. Method expressions
reference methods that can be invoked and can return a value.

Value Expressions

Value expressions can be further categorized into rvalue and lvalue expressions. Rvalue expressions are
those that can read data, but cannot write it. Lvalue expressions can both read and
write data.

All expressions that are evaluated immediately use the ${} delimiters and are always
rvalue expressions. Expressions whose evaluation can be deferred use the #{} delimiters and
can act as both rvalue and lvalue expressions. Consider these two value expressions:

The former uses immediate evaluation syntax, whereas the latter uses deferred evaluation syntax.
The first expression accesses the name property, gets its value, and the value
is added to the response and rendered on the page. The same thing
can happen with the second expression. However, the tag handler can defer the
evaluation of this expression to a later time in the page life cycle,
if the technology using this tag allows it.

In the case of JavaServer Faces technology, the latter tag’s expression is evaluated
immediately during an initial request for the page. In this case, this expression
acts as an rvalue expression. During a postback, this expression can be used
to set the value of the name property with user input. In this
situation, the expression acts as an lvalue expression.

Referencing Objects Using Value Expressions

Both rvalue and lvalue expressions can refer to the following objects and their
properties or attributes:

JavaBeans components

Collections

Java SE enumerated types

Implicit objects

See Implicit Objects for more detail on the implicit objects available with JSP technology.

To refer to these objects, you write an expression using a variable name
with which you created the object. The following expression references a JavaBeans component
called customer.

${customer}

The web container evaluates a variable that appears in an expression by looking
up its value according to the behavior of PageContext.findAttribute(String), where the String
argument is the name of the variable. For example, when evaluating the expression
${customer}, the container will look for customer in the page, request, session, and application
scopes and will return its value. If customer is not found, null is
returned. A variable that matches one of the implicit objects described in Implicit Objects
will return that implicit object instead of the variable’s value.

You can alter the way variables are resolved with a custom EL
resolver, which is a new feature of the unified EL. For instance, you
can provide an EL resolver that intercepts objects with the name customer, so that
${customer} returns a value in the EL resolver instead. However, you cannot override
implicit objects in this way. See EL Resolvers for more information on EL
resolvers.

To declare beans in JavaServer Faces applications, you use the managed bean facility.
See Backing Beans for information on how to declare beans for use in JavaServer
Faces applications.

When referencing an enum constant with an expression, you use a String
literal. For example, consider this Enum class:

public enum Suit {hearts, spades, diamonds, clubs}

To refer to the Suit constant, Suit.hearts with an expression, you use the
String literal, "hearts". Depending on the context, the String literal is converted to the
enum constant automatically. For example, in the following expression in which mySuit is
an instance of Suit, "hearts" is first converted to a Suit.hearts before it
is compared to the instance.

${mySuit == "hearts"}

Referring to Object Properties Using Value Expressions

To refer to properties of a bean or an Enum instance, items
of a collection, or attributes of an implicit object, you use the .
or [] notation, which is similar to the notation used by ECMAScript.

So, if you wanted to reference the name property of the customer bean,
you could use either the expression ${customer.name} or the expression ${customer["name"]}. The part
inside the square brackets is a String literal that is the name of
the property to reference.

You can use double or single quotes for the String literal. You can
also combine the [] and . notations, as shown here:

${customer.address["street"]}

Properties of an enum can also be referenced in this way. However,
as with JavaBeans component properties, the Enum class’s properties must follow JavaBeans component conventions.
This means that a property must at least have an accessor method called
get<Property> (where <Property> is the name of the property) so that an
expression can reference it.

For example, say you have an Enum class that encapsulates the names of
the planets of our galaxy and includes a method to get the
mass of a planet. You can use the following expression to reference the
method getMass of the Planet Enum class:

${myPlanet.mass}

If you are accessing an item in an array or list, you
must use either a literal value that can be coerced to int or
the [] notation with an int and without quotes. The following examples could
all resolve to the same item in a list or array, assuming that
socks can be coerced to int:

${customer.orders[1]}

${customer.orders.socks}

In contrast, an item in a Map can be accessed using a string
literal key; no coercion is required:

${customer.orders["socks"]}

An rvalue expression also refers directly to values that are not objects, such
as the result of arithmetic operations and literal values, as shown by these
examples:

${"literal"}

${customer.age + 20}

${true}

${57}

The unified expression language defines the following literals:

Boolean: true and false

Integer: as in Java

Floating point: as in Java

String: with single and double quotes; " is escaped as \", ’ is escaped as \', and \ is escaped as \\

Null: null

You can also write expressions that perform operations on an enum constant. For
example, consider the following Enum class:

public enum Suit {club, diamond, heart, spade }

After declaring an enum constant called mySuit, you can write the following expression
to test if mySuit is spade:

${mySuit == "spade"}

When the EL resolving mechanism resolves this expression it will invoke the valueOf
method of the Enum class with the Suit class and the spade type,
as shown here:

mySuit.valueOf(Suit.class, "spade"}

See JavaBeans Components for more information on using expressions to reference JavaBeans components and
their properties.

Where Value Expressions Can Be Used

Value expressions using the ${} delimiters can be used in the following places:

In static text

In any standard or custom tag attribute that can accept an expression

The value of an expression in static text is computed and inserted
into the current output. Here is an example of an expression embedded in
static text:

<some:tag>
some text ${expr} some text
</some:tag>

If the static text appears in a tag body, note that an
expression will not be evaluated if the body is declared to be tagdependent
(see Tags with Attributes).

Lvalue expressions can only be used in tag attributes that can accept lvalue
expressions.

There are three ways to set a tag attribute value using either
an rvalue or lvalue expression:

With a single expression construct:

<some:tag value="${expr}"/>

<another:tag value="#{expr}"/>

These expressions are evaluated and the result is coerced to the attribute’s expected type.

With one or more expressions separated or surrounded by text:

<some:tag value="some${expr}${expr}text${expr}"/>

<another:tag value="some#{expr}#{expr}text#{expr}"/>

These kinds of expression are called a composite expressions. They are evaluated from left to right. Each expression embedded in the composite expression is coerced to a String and then concatenated with any intervening text. The resulting String is then coerced to the attribute’s expected type.

With text only:

<some:tag value="sometext"/>

This expression is called a literal expression. In this case, the attribute’s String value is coerced to the attribute’s expected type. Literal value expressions have special syntax rules. See Literal Expressions for more information. When a tag attribute has an enum type, the expression that the attribute uses must be a literal expression. For example, the tag attribute can use the expression "hearts" to mean Suit.hearts. The literal is coerced to Suit and the attribute gets the value Suit.hearts.

All expressions used to set attribute values are evaluated in the context of
an expected type. If the result of the expression evaluation does not match
the expected type exactly, a type conversion will be performed. For example, the
expression ${1.2E4} provided as the value of an attribute of type float
will result in the following conversion:

Method Expressions

Another feature of the unified expression language is its support of deferred method
expressions. A method expression is used to invoke an arbitrary public method, which
can return a result. A similar feature of the unified EL is functions.
Method expressions differ from functions in many ways. Functions explains more about the differences
between functions and method expressions.

Method expressions primarily benefit JavaServer Faces technology, but they are available to any
technology that can support the unified expression language. Let’s take a look at
how JavaServer Faces technology employs method expressions.

In JavaServer Faces technology, a component tag represents a UI component on a
page. The component tag uses method expressions to invoke methods that perform some
processing for the component. These methods are necessary for handling events that the
components generate and validating component data, as shown in this example:

The inputText tag displays a UIInput component as a text field. The validator
attribute of this inputText tag references a method, called validateName, in the bean,
called customer. The TLD (see Tag Library Descriptors) that defines the inputText tag specifies
what signature the method referred to by the validator attribute must have.
The same is true of the customer.submit method referenced by the action attribute
of the commandButton tag. The TLD specifies that the submit method must return
an Object instance that specifies which page to navigate to next after the
button represented by the commandButton tag is clicked.

The validation method is invoked during the process validation phase of the life
cycle, whereas the submit method is invoked during the invoke application phase of
the life cycle. Because a method can be invoked during different phases of
the life cycle, method expressions must always use the deferred evaluation syntax.

Similarly to lvalue expressions, method expressions can use the . and []
operators. For example, #{object.method} is equivalent to #{object["method"]}. The literal inside the []
is coerced to String and is used to find the name of the
method that matches it. Once the method is found, it is invoked or
information about the method is returned.

Method expressions can be used only in tag attributes and only in
the following ways:

With a single expression construct, where bean refers to a JavaBeans component and method refers to a method of the JavaBeans component:

<some:tag value="#{bean.method}"/>

The expression is evaluated to a method expression, which is passed to the tag handler. The method represented by the method expression can then be invoked later.

With text only:

<some:tag value="sometext"/>

Method expressions support literals primarily to support action attributes in JavaServer Faces technology. When the method referenced by this method expression is invoked, it returns the String literal, which is then coerced to the expected return type, as defined in the tag’s TLD.

Defining a Tag Attribute Type

As explained in the previous section, all kinds of expressions can be used
in tag attributes. Which kind of expression and how that expression is evaluated
(whether immediately or deferred) is determined by the type attribute of the tag’s
definition in the TLD (see Tag Library Descriptors) file that defines the tag.

If you plan to create custom tags (see Chapter 8, Custom Tags in JSP Pages), you need to
specify for each tag in the TLD what kind of expression it accepts.
Table 5-2 shows the three different kinds of tag attributes that accept EL expressions,
and gives examples of expressions they accept and the type definitions of the
attributes that must be added to the TLD. You cannot use #{}
syntax for a dynamic attribute, meaning an attribute that accepts dynamically-calculated values at runtime.
Section 2.3.2 of the JavaServer Pages 2.1 specification refers to these attributes. Neither
can you use the ${} syntax for a deferred attribute.

In addition to the tag attribute types shown in Table 5-2, you can
also define an attribute to accept both dynamic and deferred expressions. In this
case, the tag attribute definition contains both an rtexprvalue definition set to
true and either a deferred-value or deferred-method definition.

Deactivating Expression Evaluation

Because the patterns that identify EL expressions, ${ } and #{ }, were not reserved in
the JSP specifications before JSP 2.0, there might exist applications in which such
patterns are intended to pass through verbatim. To prevent the patterns from being
evaluated, you can deactivate EL evaluation using one of the following methods:

Escape the #{ or ${ characters in the page.

Configure the application with a JSP Property Group.

Configure the page with the page directive.

To escape the #{ or ${ characters in the page, you use the
\ character as follows:

Another way to deactivate EL evaluation is by using a JSP property
group to either allow the #{ characters as a String literal using the deferred-syntax-allowed-as-literal
subelement, or to treat all expressions as literals using the el-ignored subelement:

Finally, you can configure the page with the page directive to either accept
the #{ characters as String literals with the deferredSyntaxAllowedAsLiteral attribute, or to ignore all
EL expressions using the isELIgnored attribute:

<%@page ... deferredSyntaxAllowedAsLiteral="true" %>

or

<%@ page isELIgnored ="true" %>

The valid values of these attributes are true and false. If isELIgnored
is true, EL expressions are ignored when they appear in static text or
tag attributes. If it is false, EL expressions are evaluated by the container only
if the attribute has rtexprvalue set to true or the expression is a
deferred expression.

The default value of isELIgnored varies depending on the version of the web
application deployment descriptor. The default mode for JSP pages delivered with a Servlet
2.4 descriptor is to evaluate EL expressions; this automatically provides the default that
most applications want. The default mode for JSP pages delivered using a descriptor
from Servlet 2.3 or before is to ignore EL expressions; this provides backward
compatibility.

Literal Expressions

A literal expression evaluates to the text of the expression, which is of
type String. It does not use the ${} or #{} delimiters.

If you have a literal expression that includes the reserved ${} or
#{} syntax, you need to escape these characters as follows.

By creating a composite expression as shown here:

${’${’}exprA}

#{’#{’}exprB}

The resulting values would then be the strings ${exprA} and #{exprB}.

The escape characters \$ and \# can be used to escape what would otherwise be treated as an eval-expression:

\${exprA}

\#{exprB}

The resulting values would again be the strings ${exprA} and #{exprB}.

When a literal expression is evaluated, it can be converted to another type.
Table 5-3 shows examples of various literal expressions and their expected types and resulting
values.

Table 5-3 Literal Expressions

Expression

Expected Type

Result

Hi

String

Hi

true

Boolean

Boolean.TRUE

42

int

42

Literal expressions can be evaluated immediately or deferred and can be either value
or method expressions. At what point a literal expression is evaluated depends on
where it is being used. If the tag attribute that uses the literal
expression is defined as accepting a deferred value expression, then the literal expression
references a value and is evaluated at a point in the life cycle
that is determined by where the expression is being used and to what
it is referring.

In the case of a method expression, the method that is referenced
is invoked and returns the specified String literal. The commandButton tag of the
Guess Number application uses a literal method expression as a logical outcome to
tell the JavaServer Faces navigation system which page to display next. See Navigation Model
for more information on this example.

Resolving Expressions

The unified EL introduces a new, pluggable API for resolving expressions. The main
pieces of this API are:

The ValueExpression class, which defines a value expression

The MethodExpression class, which defines a method expression

An ELResolver class that defines a mechanism for resolving expressions

A set of ELResolver implementations, in which each implementation is responsible for resolving expressions that reference a particular type of object or property

An ELContext object that saves state relating to EL resolution, holds references to EL resolvers, and contains context objects (such as JspContext) needed by the underlying technology to resolve expressions

Most application developers will not need to use these classes directly unless they
plan to write their own custom EL resolvers. Those writing JavaServer Faces custom
components will definitely need to use ValueExpression and MethodExpression. This section details
how expressions are resolved for the benefit of these developers. It does not
explain how to create a custom resolver. For more information on creating custom
resolvers, see the article The Unified Expression Language, Ryan Lubke et al., located at http://java.sun.com/products/jsp/reference/techart/unifiedEL.html.
You can also refer to Request Processing, which explains how the Duke’s Bank
application uses a custom resolver.

Process of Expression Evaluation

When a value expression that is included in a page is parsed
during an initial request for the page, a ValueExpression object is created to represent
the expression. Then, the ValueExpression object’s getValue method is invoked. This method
will in turn invoke the getValue method of the appropriate resolver. A
similar process occurs during a postback when setValue is called if the expression is
an lvalue expression.

In the case of a method expression, a BeanELResolver is used to find
the object that implements the method to be invoked or queried. Similarly to
the process for evaluating value expressions, when a method expression is encountered, a
MethodExpression object is created. Subsequently, either the invoke or getMethodInfo method of the MethodExpression
object is called. This method in turn invokes the BeanELResolver object’s getValue method.
The getMethodInfo is mostly for use by tools.

After a resolver completes resolution of an expression, it sets the propertyResolved
flag of the ELContext to true so that no more resolvers are
consulted.

EL Resolvers

At the center of the EL machinery is the extensible ELResolver class. A
class that implements ELResolver defines how to resolve expressions referring to a
particular type of object or property. In terms of the following expression, a
BeanELResolver instance is called the first time to find the base object,
employee, which is a JavaBeans component. Once the resolver finds the object, it
is called again to resolve the property, lName of the employee object.

${employee.lName}

The unified EL includes a set of standard resolver implementations. Table 5-4 lists
these standard resolvers and includes example expressions that they can resolve.

Table 5-4 Standard EL Resolvers

Resolver

Example Expression

Description

ArrayELResolver

${myArray[1]}

Returns the
value at index 1 in the array called myArray

BeanELResolver

${employee.lName}

Returns the value of
the lName property of the employee bean

ListELResolver

${myList[5]}

Returns the value at index 5
of myList list

MapELResolver

${myMap.someKey}

Returns the value stored at the key, someKey, in the Map,
myMap

ResourceBundleELResolver

${myRB.myKey}

Returns the message at myKey in the resource bundle called myRB

Depending on the technology using the unified EL, other resolvers might be available.
In addition, application developers can add their own implementations of ELResolver to support
resolution of expressions not already supported by the unified EL by registering them
with an application.

All of the standard and custom resolvers available to a particular application are
collected in a chain in a particular order. This chain of resolvers
is represented by a CompositeELResolver instance. When an expression is encountered, the CompositeELResolver instance iterates
over the list of resolvers and consults each resolver until it finds one
that can handle the expression.

If an application is using JSP technology, the chain of resolvers includes the
ImplicitObjectELResolver and the ScopedAttributeELResolver. These are described in the following section.

See section JSP 2.9 of the JavaServer Pages 2.1 specification to find out
the order in which resolvers are chained together in a CompositeELResolver instance.

JSP 2.1 provides two EL resolvers to handle expressions that reference these objects:
ImplicitObjectELResolver and ScopedAttributeELResolver.

A variable that matches one of the implicit objects is evaluated by
ImplicitObjectResolver, which returns the implicit object. This resolver only handles expressions with a
base of null. What this means for the following expression is that the
ImplicitObjectResolver resolves the sessionScope implicit object only. Once the implicit object is found,
the MapELResolver instance resolves the profile attribute because the profile object represents a map.

${sessionScope.profile}

ScopedAttributeELResolver evaluates a single object that is stored in scope. Like ImplicitObjectELResolver, it also
only evaluates expressions with a base of null. This resolver essentially looks for
an object in all of the scopes until it finds it, according to
the behavior of PageContext.findAttribute(String). For example, when evaluating the expression ${product}, the resolver
will look for product in the page, request, session, and application scopes and
will return its value. If product is not found, null is returned.

When an expression references one of the implicit objects by name, the appropriate
object is returned instead of the corresponding attribute. For example, ${pageContext} returns the
PageContext object, even if there is an existing pageContext attribute containing some other value.

Operators

In addition to the . and [] operators discussed in Value and Method Expressions, the JSP expression
language provides 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

? :

Reserved Words

The following words are reserved for the JSP expression language and should not
be used as identifiers.

and

or

not

eq

ne

lt

gt

le

ge

true

false

null

instanceof

empty

div

mod

Note that many of these words are not in the language now,
but they may be in the future, so you should avoid using them.

Examples of EL Expressions

Table 5-5 contains example EL expressions and the result of evaluating them.

Table 5-5 Example Expressions

EL Expression

Result

${1 > (4/2)}

false

${4.0 >= 3}

true

${100.0 == 100}

true

${(10*10) ne 100}

false

${'a' < 'b'}

true

${'hip' gt 'hit'}

false

${4 > 3}

true

${1.2E4 + 1.4}

12001.4

${3 div 4}

0.75

${10 mod 4}

2

${!empty param.Add}

False if
the request parameter named Add is null or an empty string.

${pageContext.request.contextPath}

The context path.

${sessionScope.cart.numberOfItems}

The
value of the numberOfItems property of the session-scoped attribute named cart.

${param['mycom.productId']}

The value of
the request parameter named mycom.productId.

${header["host"]}

The host.

${departments[deptName]}

The value of the entry named deptName
in the departments map.

${requestScope[’javax.servlet.forward.servlet_path’]}

The value of the request-scoped attribute named javax.servlet.forward.servlet_path.

#{customer.lName}

Gets the
value of the property lName from the customer bean during an initial
request. Sets the value of lName during a postback.

At first glance, functions seem similar to method expressions, but they are different
in the following ways:

Functions refer to static methods that return a value. Method expressions refer to non-static, arbitrary public methods on objects.

Functions are identified statically at translation time, whereas methods are identified dynamically at runtime.

Function parameters and invocations are specified as part of an EL expression. A method expression only identifies a particular method. The invocation of that method is not specified by the EL expression; rather, it is specified in the tag attribute definition of the attribute using the method expression, as described in Defining a Tag Attribute Type.

Using Functions

Functions can appear in static text and tag attribute values.

To use a function in a JSP page, you use a taglib
directive to import the tag library containing the function. Then you preface the
function invocation with the prefix declared in the directive.

For example, the date example page index.jsp imports the /functions library and invokes
the function equals in an expression:

In this example, the expression referencing the function is using immediate evaluation syntax.
A page author can also use deferred evaluation syntax to reference a function
in an expression, assuming that the attribute that is referencing the function can
accept deferred expressions.

If an attribute references a function with a deferred expression then the function
is not invoked immediately; rather, it is invoked whenever the underlying technology using
the function determines it should be invoked.

Defining Functions

To define a function, program it as a public static method in a
public class. The mypkg.MyLocales class in the date example defines a function that
tests the equality of two Strings as follows:

Then map the function name as used in the EL expression to
the defining class and function signature in a TLD (see Chapter 8, Custom Tags in JSP Pages). The following
functions.tld file in the date example maps the equals function to the class containing
the implementation of the function equals and the signature of the function: