Skip to main content

Java EE WebTier Expression Language: simplicity and feature-set tradeoff

Posted by pierre on June 27, 2005 at 7:43 AM PDT

There have been a couple blogs recently regarding "bloating" (Eclipse, Mustang). Whoever has been on a design team that has to decide which feature goes in and which one stays out will probably feel the pain. As a spec lead (JSP, JSTL), I sure do. We all wish we could please everyone, but that's unrealistic. One has to accept that some developers will be unhappy with the decisions made. However, these days, it is often the case that a developer's voice can be heard before these decisions are made, and it can make a difference. Anyone with a strong opinion should make sure to take advantage of this...

In Java EE webtier land, we've worked hard over the last few releases to simplify the life of page authors (those that code the JSP pages). There's been many improvements to JSP, as well as the introduction of both the JSP Standard Tag Library and JavaServer Faces. One key element of our simplification effort has been the Expression Language (EL), which simplifies access to application data for the presentation layer. The EL (which by the way was first known as SPEL, the Simplest Possible Expression Language) started with JSTL 1.0, and was later picked up in parallel by JSP 2.0 and JSF 1.0. JSF's version of the EL diverged slightly from the JSP version because of its unique requirements (mostly defferred evaluation and support for method expressions). With the upcoming releases of JSP 2.1 and JSF 1.2, the two expert groups (EGs) have worked together to merge these differences into a common Unified EL, with an API that makes the EL much more flexible so it better adapts to the diverse needs of Java EE webtier technologies.

From its inception, the key design goal of the EL has been simplicity. It is commonly acknowledged these days that complex code should be written and maintained outside of view pages, and the expert groups have evolved the specs to better support this model. There have been some discussions recently on The Server Side comparing the EL with OGNL, with some complaining about shortcomings in the EL. I won't get into the details here, but it is clear that the expert group will have some tough calls to make regarding the evolution of the EL. While we don't want to lose sight of our base requirement for simplicity, we also do not want to alienate a large number of developers who strongly believe that a few important new features should be added to ensure improved usability of the EL. But the key point here is that the EG does not want to make any decision out of thin air. We do care about the community's input. Which finally brings me to the point I'd like to make in this blog.

There were some excellent comments made in that TSS discussion thread. Luckily, someone notified me and I will make sure that the EG follows up on them. There's obviously much more we can learn from the community, and I want to make sure it gets to our EGs. As I blogged last year, the new JCP 2.6 creates more transparency into the specification work performed by the Expert Groups. Many specifications (e.g. JSP, JSTL, Faces) have a project at to help developers stay abreast of the work done on on these JSRs. Use the mailing list to voice your opinion on any aspect of the spec, and browse/submit issues related to a spec through the issue tracker. The likelihood of an issue being tackled by the expert group is much higher if a comment is submitted through these official channels. And it will make our tough calls much easier to make if we do have lots of data points to work with. We know we won't be able to please everyone, but we'll definitely listen to all.

And by the way, as you probably all know by now, GlassFish is out, and it is open source. It's got most (if not all) the new JSP 2.1/JSF 1.2 features implemented. Take it for a spin and experiment with the improved JSP/JSF integration, as well as the unified EL. And don't forget to send us comments...

Related Topics >>