Ed Burns is co-specification lead for JSR 252, JavaServer Faces 1.2, and Jan Luehe
leads JSR 245, Java Server Pages 2.1. Artima interviewed the two spec leads
on April 14, 2006, and then in a subsequent email exchange, about new JSF and JSP
features included in Java EE 5. Burns and Luehe discuss the JSP and JSF common
expression language, AJAX, and the role annotations play in dependency injection.

Frank Sommers: What are the new features in the latest JSP and JSF specifications?

Ed Burns: The main theme of Java EE 5 is ease of development, and the key new JSP
and JSF features echo this desire. Both technologies evolved over many years, and
what you see now in the current specification versions is the result of that
evolution.

Before delving into the details of new JSP and JSF features, it might help your
readers if I explained a bit the history of these specs. JSP [together with the
Servlet API] was one of the earlier specifications, starting sometime around the year
2000, but the technology predated that initial JSR. At that time, the specs were
defining Servlet 2.3 and JSP 1.2, and would then become part of J2EE 1.3.

JSF 1.0 came out around February of 2004 as an independent technology [of J2EE],
and it relied on Servlet 2.3 and JSP 1.2. JSF defined a standard UI model for the
Web. Many people confuse it with an application framework, but it's really a
component framework. Components have properties, methods, and events, and that's what JSF brings to Web programming.

JSF 1.0 had important innovations to deliver on its own schedule. JSF 1.1 was
mainly a bug- fix release [Editor's note: also developed as JSR 127] and worked with
the same version of the Servlet API as JSF 1.0 did. The first version of the JSF spec
to be included in Java EE is the current version, JSF 1.2, and it works with Servlet
2.5 and JSP 2.1, which are also part of Java EE 5.

While it may be confusing at first to look at these version changes, it helps in
understanding how JSP and JSF technologies evolved relatively independently until
recently. The main thrust of the current JSF and JSP specs has been the desire the
align these technologies. That's in keeping with the Java EE 5 theme of ease of
development, and the JSF and JSP expert groups worked very hard together to ensure
that the resulting specs make it easier to work with JSF and JSP together.

At the heart of the JSP-JSF alignment is a unified expression language. JSP included an
expression language since the 1.2 version, but because these technologies have different
purposes—for instance, JSP and JSF component life cycles are different—their respective
expression languages did not align well with each other. Although part of the JSP 2.1 release,
the unified expression language now has its own specification, and we can imagine uses of
this expression language outside of JSF as well.

Jan Luehe: We also added features to align these specs with other parts of Java EE 5.
Again, here the chief goal was to provide greater development ease. We now have
annotations that can potentially reduce the amount of code a developer has to write. For
instance, you can use annotations to specify dependency injection in servlets now. JSPs can
take advantage of the entire Java EE 5 persistence model as well.

Unified Expression Language

Frank Sommers: You mentioned that the unified expression language now lives in its own
specification document. What was the reason for that separation?

Ed Burns: JSF 1.1 delivered many innovations for Web developers, and we wanted to
expose some of those outside of JSF, mainly so that JSP can take advantage of them. The
result is that the expression language is now independent of its hosting technology. In time,
we might expose this expression language even outside of Java EE, and at some point it may
even occupy its own JSR.

For example, one of the things we are considering is for this expression language to provide
data binding in Java SE applications. It would probably be a sub-language for data binding,
similar to how the expression language is used to obtain values from a JSF component. In
[Java] SE, it might be a Swing expression language.

Frank Sommers: What differentiates an expression language from a scripting language?

Ed Burns: An expression language, or EL, is not a full-fledged programming language—you
can't write programs in an expression language. Instead, an expression language is used
mainly as a short-hand for accessing values. It makes it easy for page authors to access
variables within different scopes, for instance, and to access properties of values. In addition,
expression languages provide the notion of having some model data, and can help in
navigating that model data.

An expression language often comes with some predefined values with a scope, such as a
page context. The expressions are resolved within that scope. And you can specify what that
context is. In the unified JSF/JSP expression language, whenever you evaluate an
expression, you provide the context for that evaluation. In other words, you specify the
context in which a variable can be defined. In the JSP context, for instance, the variable
scopes are page, session, or application.

The application developer provides an EL context factory. Of course, we provide some base
classes for those context factories. But the interesting part is that the whole notion of these
contexts are general, and we didn't include any Web concepts in the EL core. All those [Web-
specific concepts] are brought into the EL by the application. The independence of the unified
EL from Web technologies is reflected in that we promoted the EL-related classes into their
own package, javax.el.

The context you specify is then taken into account as a model object name is evaluated into
an object reference, and as object properties are resolved. This is done by one or more EL
resolvers, defined by an ELResolver implementation. A resolver takes a part
of an expression, a name-to-value reference, and resolves that to an object reference. There
can be a chain of resolvers. Each element of the chain might be able to resolve a part of the
expression within a context the resolver knows about.

You can decide what kind of resolvers to add into this resolver chain. In JSF, for instance, you
have a managed bean resolver that knows how to resolve references in the context of
managed beans. Or you have a JavaBean EL resolver: Given a POJO, it looks for naming
conventions to resolve a value. For instance, if you say, user.address.street in
the EL, the bean resolver would be used to resolve that expression to an object value given
the bean naming patterns.

Within the context of the resolvers, expressions act as a means to
get a value, and also as a means to set a value. For example, when
rendering an input field, the initial render of the field may or may
not have a default value. If it does, the default value will be
obtained by performing a "get" operation. However,
when the value of the field is filled in by the user and submitted to
the server, the expression receives that value by performing a "set"
operation on the server.

This is an important point, because it provides for plugability in the architecture. If a value
cannot be resolved within the context of one resolver, resolution attempts will [bubble up] the
chain of resolvers. So to support, say, the Spring Framework, you would plug in resolvers
specific to Spring, and then the system can manipulate Spring beans.

The EL itself defines no [technology-specific] resolvers. The core EL package defined in
javax.el provides only basic resolvers, such as those capable of operating on
maps, arrays, or beans. Apart from these abstract resolvers, each technology, such as JSP
and JSF, and possibly others taking advantage of javax.el, defines
technology-specific resolvers.

Jan Luehe: There is also a concept of delayed evaluation of an expression. In the old-style
notation, with $ and curly braces surrounding the expression, the expression is compiled
when the JSP is compiled, and is evaluated once, when the JSP executes. We also have
another way to specify eval-expressions in the JSP and JSF contexts, and that is to use #
instead of $. [Editor's note: Eval-expressions are expressions that require evaluation, as
opposed to literal expressions.] Such a deferred-evaluation expression is not evaluated until
its value is needed. This is especially useful in JSF, where the component life cycle is not tied
to page execution. While the latest JSP and JSF specs are backwards compatible with earlier
versions, if you want to take advantage of the delayed-evaluation feature, then you must
upgrade.

AJAX and Annotations

Frank Sommers: What AJAX-related features were added to JSF and JSP?

Ed Burns: While a lot could be done with JSF and AJAX beyond what we provide now, the
JSF and JSP spec leads had to work within the constraints of time in terms of what we could
do. We did make some key changes in the JSF API to help AJAX-style applications. These
build on JSF's strength in state management—JSF components maintain their own state.
With AJAX, you can transfer that state back and forth between server and component. There
are many ways of doing that, and we don't specify one particular way in the JSF specs.

JSF's ability to maintain state within the component comes in handy in many AJAX use-cases. For instance, in a drop-down list, when the user selects a list item, that selection can
cause another part of the page to show. To enable that state transfer [of the component's
serialized state], the JSF state model included a hidden field that contained the component's full
serialized state. We now standardized the name of that hidden field, and you can access that
field from within AJAX.

Another interesting JSF feature that helps with AJAX development is life-cycle listeners. JSF
provides listeners on the component life-cycle. But you can provide custom life-cycle listeners
on a per servlet basis. You can have life-cycle listeners that process AJAX-based events, and
events occurring in the view. Suppose you want to use Faces validation, and set a specific
database validation listener on a component. With a per-view listener, you can attach a
listener to the view, and use that listener to take action for validation [when some aspect of
the view changes]. The benefit of the per-View phase listener is that it doesn't affect all requests, just ones to that view.

It's worth noting that there is now a growing library of AJAX-enabled JSF components. We're
just now going public with a set of nine components that you can
run in Java Studio Creator. The components include an AJAX file-upload component, an
AJAX progress bar, a pop-up bubble. Another interesting component in this library is an AJAX
validator, and this goes back to life-cycle processing. When doing client-side validation you
can't take advantage of the JSF-provided life-cycle elements. Yet you often want validation to
be part of a component's life-cycle. For instance, before updating the model data, you may
always want to ensure that the data matches [validation requirements]. This component
wraps validation into a JSF life cycle.

The validator component is handy for those cases when mere
syntactic validation, as often practiced in pure client side
validation, is not sufficient. For example, a credit card number can
be syntactically validated to ensure that it contains sixteen digits.
This can and should be done entirely on the client. However, to
verify that the account is active and in good stead requires a server
transaction. Requiring the user to do a full page refresh just to get
this data would be a hassle. The Ajax validator component enables
wrapping any JSF component with any JSF validator, and running just
the validation part of the lifecycle on that specific component
instance.

Frank Sommers: You mentioned dependency injection and annotations. How do annotations
help a JSF and JSP developer?

Jan Luehe: You can now inject dependencies, such as resources, into JSF. An example is a
managed bean. All other Web tier technologies have taken advantage of dependency
injection as well: In JSP, you can inject a tag handler, in servlets, a servlet or a servlet filter.
You also inject these into custom JSP tags as well.

An interesting example of how this helps is in conjunction with the new Java persistence API
in Java EE 5. You can inject a persistence context or a JDNI resource into a JSP or servlet by
sticking an annotation into a custom tag. This avoids having to write a lot of boiler-plate code.

Consider a servlet that increments and persists in a database the number of times the person
identified by the request parameter "name" has been greeted. If the servlet was mapped to
/HelloServlet in samples.war, an invocation of it might look as
follows:

http://:/samples/HelloServlet?name=tom

Prior to dependency injection, the servlet would look up and update a JNDI resource, like this:

APPENDIX

The following code examples show three versions of the same servlet. Listing 1 shows how a data source is obtained via a JNDI lookup. Listing 2 injects the data source as a dependency into the servlet, alleviating the need to use JNDI. Listing 3 shows how the same servlet can use EJB 3 persistence to further simplify what a developer has to write.