JavaServer Pages 2.1, JSR 245, has been approved by the JCP executive committee with Oracle, Nortel, and Google abstaining without comment.

This release focuses on issues concerning the JSP expression language and integration with JavaServer Faces. As summarized before on TSS, the changes approved for JSP centered around the following elements:

• JspApplicationContext - This class contains context information specific to JSP containers, and allows pluggable expression language resolvers
• Expression Language changes - A new package for expression language classes was created, and the old package was deprecated. Many new features were added to the expression language.
• Tag library changes - New rules and capabilities for the use of tag files and libraries were added.
• trimWhiteSpaces directive - A JSP page can now be directed to remove whitespaces after JSP directives that do not have any other content after them.
• Minor bugfixes to the JSP 2.0 specification.

JSP 2.1 is being targeted for J2EE 1.5.

Reading the spec, it seems that you can access a bean property, array index, list index or map entry using the EL syntax. But not make a call onto a bean method like toDate().

This greatly affects many projects (like my own Joda-Time) where various methods that you want to call from EL are named toXxx() or withXxx() instead of getXxx().

However, perhaps it is possible for us to implement ElResolver ourselves to do this? And register this into JSF/JSP?

Why just not throw that crappy EL thing out of the window and use OGNL instead?

Why just not throw that crappy EL thing out of the window and use OGNL instead?

EL has a very specific purpose in providing the 'view' the ability to read properties avialable in scope. Lets imagine for a second that all JSP development was done with OGNL. With OGNL, you are opening up a whole subset of functionality that is exposed to the view layer of your application. Most architects don't like this idea.

With the new EL API, ValueExpressions and MethodExpressions are provided to more greatly enhance the request/response lifecycle of the web. An expression can be created on one response to the browser, then invoked later in a subsequent request back to the server. JavaServer Faces uses this functionality for easy page/component development (model 1).

So for those that are looking for OGNL functionality-- go ahead and use it. For the common case, EL is there and provides the features that most developers are looking for. During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything...

Jacob Hookom (JSR 252 & EL)
JSF Facelets

With OGNL one could do quite innocent, read-only operations like
"blah instanceof my.app.package.Klass"
or
"blah == @my.app.package.Klass@STATIC"

And honestly I don't really care what would so-called "architects" say here. Everything you can access from OGNL are just beans; so if you don't trust those developer guys, expose only View Helper read-only beans available to them. Poor coders are no excuse for use of restricting technology.

With OGNL one could do quite innocent, read-only operations like
"blah instanceof my.app.package.Klass"
or
"blah == @my.app.package.Klass@STATIC"

Another person might say that code like that has no reason to be contained in the view. I see the point you are making and have looked at OGNL in the past, but I, like many, believe that putting scripting language in the view isn't the right course of action as a *standard*-- that's the clear emphasis here.

With earlier versions of JSP, the only tool available was scriplets (<% %>). This has quickly fallen out of favor as being hard to maintain, poor practice, whatever. Resultingly, EL has since replaced scriplets as the standard practice in JSP and JSPX.

Truthfully, I wouldn't consider the EL-API a scripting language by any means, but a way of expressing pointers to data you need. The new EL-API really emphasises this point with being able to create and save EL 'pointers' or Expressions for use later. This includes Method invocation with MethodExpressions.

-- Jacob

EL should be used to read properties in the view. I agree with that. However, there are two things that I don't like with EL.

First, it's not possible to have access to constants.
For example, I often have to display select boxes with constants as values. Hardcoding the value of the constant in the page doesn't seem good to me. So I often have to add stupid getters to my beans to access the constants:
<code>
  public int getNEVER() {
    return Constants.NEVER;
  }
  public int getSOMETIMES() {
    return Constants.SOMETIMES;
  }
  public int getALWAYS() {
    return Constants.ALWAYS;
  }
</code>

And these getters can't even be static, because the EL can't call them if they are.

The second thing I don't like is that I can't access indexed properties. The only possible way is to put them into a Map, and expose the map to the outside, which breaks encapsulation IMHO.

With suggestions of constants and indexed bean properties, I would recommend that you email the JSR EG at jsr-245-comments at jcp dot org, your suggestions are then submitted to the group for voting and discussion.

Otherwise you can get involved in the JCP process in the future by going to jcp.org. Speaking from experience, I don't work for any vendor, just a medical company, and wanted to participate in the design of JSF and JSP. I recommend more people do the same.

-- Jacob

During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything...

Yes, it tells me that the people writing the spec don't actually use the technology that they are defining (a problem that has come up repeatedly with JSR specs).

Let me explain the exact case where this matters to Joda-Time. We provide a complete set of replacement date and time classes, which are often used as JavaBean properties. However, various jsp tags still expect a Date or Calendar object as input.

Joda-Time provides great interoperability methods called toDate() and toGregorianCalendar() which are designed to be used in cases like this (and which follow the Sun naming conventions for methods of this type). However, EL (and thus JSP/JSF) can't use these methods because of the spec writers 'holier than thou' attitide against method calls.

Thus, instead of:<br />
  <fmt:formatDate value="${myBean.startDate.toDate()}"/><br />

I have to do:
<% MyBean bean = (MyBean)pageContext.findAttribute("myBean");
   java.util.Date startDate = bean.getStartDate().toDate();
   pageContext.setAttribute("startDate", startDate);
 %>
 <fmt:formatDate value="${startDate}"/>

The good news is that another alternative is to write my own ELResolver. The bad news is that I have to code it, maintain it, make it available from the Joda-Time website, teach people to use it and thats its 'non-standard'. (Code and effort that will probably be dupilcated by many people across many projects)

So, are you still convinced that You're right and all of us developers need to be constrained?

During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything...

Yes, it tells me that the people writing the spec don't actually use the technology that they are defining (a problem that has come up repeatedly with JSR specs).

That couldn't be farther from the truth. There are many developers participating in the spec, and there are many developers out 'in the trenches', like myself that see issues/advantages pop up in development.

Let me explain the exact case where this matters to Joda-Time. We provide a complete set of replacement date and time classes, which are often used as JavaBean properties.

As to why Joda Time didn't just extend java.util.Date is beyond me. It would have made Joda Time much more interoptable with every other solution out there-- JSTL for one, ORM solutions, etc.

The good news is that another alternative is to write my own ELResolver. The bad news is that I have to code it, maintain it, make it available from the Joda-Time website, teach people to use it and thats its 'non-standard'.

Hey, so is Joda-Time, but we know that's not the point you are trying to prove. Conversions are often times done with the FunctionMapper "jd:toUtil(jodaDate)".

 (Code and effort that will probably be dupilcated by many people across many projects)So, are you still convinced that You're right and all of us developers need to be constrained?

What it comes down to is while it is easier to simply do dot notation for method invocation-- really it is, we've found ways to be able to provide the same behavior in other ways-- function mappers, method expressions, etc-- without turning EL into a scripting language-- that is *not* EL's intentions.

-- Jacob

When did it become [OT] to criticise the spec being referenced in the thread?

As to why Joda Time didn't just extend java.util.Date is beyond me. It would have made Joda Time much more interoptable with every other solution out there-- JSTL for one.

We don't subclass it because ther is no 'is-a' relationship. Date has very odd semantics that probably 99% of its users don't really realise. (ie. it is not technically feasible for us to extend Date) Joda-Time gets away from those weird semantics, in fact thats part of its raison d'etre.

Anyway, this is NOT a thread about Joda-Time, but about an entire set of pre-existing Java classes/methods that EL will not work with in a simple manner.

Conversions are often times done with the FunctionMapper "jd:toUtil(jodaDate)".

But why? Why does every EL user need to write a static method function every time they want to convert an object from one type to another? Why can't EL users just call the conversion method already written on the object using Sun's naming conventions? Am I supposed to rename the method to getAsDate() ?!!! Its just exasperating.

What it comes down to is while it is easier to simply do dot notation for method invocation-- really it is, we've found ways to be able to provide the same behavior in other ways-- function mappers, method expressions, etc-- without turning EL into a scripting language-- that is *not* EL's intentions.

At least we are clear that it is an architectural choice. IMHO, the wrong one, as it makes your user's lives harder for little, if any, technical benefit.

When did it become [OT] to criticise the spec being referenced in the thread? ... Anyway, this is NOT a thread about Joda-Time....

... Exactly.

EL is founded on the JavaBean specs, not general naming conventions. I like the idea of incorporating 'toXXX' within JSF or providing a JSP convert tag that is similar to c:set that works off of 'toXXX' in order to provide the functionality you expect.

Again, I recommend that you send comments to the JSR group for consideration. It's kind of like electing a president... if you didn't vote or weren't involved in the first place, then it's hard to complian after the fact.

-- Jacob

And there I was thinking that an example would be a good way to make a general point.

I can understand your fustration at people not getting involved in your JSR, however IMHO it is just impossible to maintain an interest in every single project or JSR going on in the world of Java. Thus we rely on the expert group members making the right choices.

I will try to find time to write to the expert group. However, my previous experience of JSR involvement wasn't terribly positive, so I'm not exactly enthused.

During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything...

Yes, it tells me that the people writing the spec don't actually use the technology that they are defining (a problem that has come up repeatedly with JSR specs).

That couldn't be farther from the truth. There are many developers participating in the spec, and there are many developers out 'in the trenches', like myself that see issues/advantages pop up in development.

I have to agree with Stephen here. _Every_ single time I've had to write a serious app using JSPs and JSTL, I've cursed the inability in JSTL to call more than basic getter methods and access collection elements, to get at part of my doomain object graph that is being exposed to the view as model data. This is not about the view being able to modify data, but simply about being able to access that data. Consider the simple example of a variant of a 'getter' method that needs to take one or two 'qualifiers' or key values. A typical domain object graph will have a decent number of access mechanism for objects in the graph that are not expressed as simple JavaBean getter methods or collection access.

So over and over again I find myself in the situation where my service layer has passed up what should be a perfectly usable object graph to my view layer, and then I have to morph that to another object hierarchy or or stuff it in some collections, etc., just so my JSTL code can access it.

On the other hand, I've used and seen used OGNL in Tapestry apps, with full access to the methods of objects being exposed to the view, with no ill effects, and a lot less hassles and unneeded code.

To me, this is a sign of a fundamentally bad assumption on the part of the spec team, that people using the expression language can not be trusted, so their access should be limited. The onus of trust should instead be placed on what object graph is exposed to the view template technology (i.e. limit that object graph), and then letting the view template technology fully access that object graph.

Regards,
Colin


--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

To me, this is a sign of a fundamentally bad assumption on the part of the spec team, that people using the expression language can not be trusted, so their access should be limited. The onus of trust should instead be placed on what object graph is exposed to the view template technology (i.e. limit that object graph), and then letting the view template technology fully access that object graph.

To be fair, the fact that EL isn't a scripting language and doesn't provide the same features as OGNL, it allows other unique usecases to take place in conjunction within a framework.

A lot of times when you think of EL or OGNL in the 'view', it's being created, evaluated, and rendered at once. With the EL-API, you can create separation such that expressions can be created, serialized, chained, and executed multiple times later.

For example, take the concept of iteration. This proves to be more difficult than one might think in relation to deferred evaluation when you want multiple expressions to work in conjuction with each other at a later time. If we opened up the BNF to 'inlined' method invocation with parameters, we start running into issues that would be a mess for anyone to really grasp on a case by case basis-- given the lifecycle that the EL-API provides to frameworks.

I agree that inlined method invocation would be nice to have, but the proposal has been brought up multiple times in the EG and gets riddled with holes (one of which I touch on above).

-- Jacob

Or better yet...just use Java!

Why the hell did they come up with all of these stupid 'expression langauges' to avoid coding in java. This was dumb of Sun.

I have never seen anyone use this crap.

The power of Java in the JSP is something wonderful. No reflection. No need to use 'beans'. No need to use taglibs. Just pure high performance pages.

Life is great without all of this crap.

It's like the designers got together and said 'lets see how many layers of indirection we can provide in the name of simplicity'.

It's dumb I tell you.

Reading the spec, it seems that you can access a bean property, array index, list index or map entry using the EL syntax. But not make a call onto a bean method like toDate().This greatly affects many projects (like my own Joda-Time) where various methods that you want to call from EL are named toXxx() or withXxx() instead of getXxx().However, perhaps it is possible for us to implement ElResolver ourselves to do this? And register this into JSF/JSP?

Yes, you can provide your own ELResolver within your web app to resolve your own properties/variables.

Jacob Hookom (JSR 252 & EL)
JSF Facelets

any news about a new version of these containers to support the new specs

Being able to call a method on a Java object is very useful.

Unfortunaley over the 5 years there has been a great amount of "architectural" confusion in the J2EE Web space. People have labelled web frameworks as MVC designs, and have confused application layering in the process.

In most rich GUI components they are both the View and the Control. MVC is design pattern for special cases when you have multiple views onto the same model, being notified in an Observer style pattern. This really has very little to do with the usual web Command pattern, where people call DAOs 'models', JSP 'views' and Actions/Commands/Servlets etc 'controls'.

JSP/Taglibs make it very difficult to encapsulate the control functionality of a GUI component, as they are really write only objects. However people think this is OK because they are the "View" "layer". Please note architectural layering is a different concept.

The end result is that we have J2EE web technologies with very poor encaspulation, making development difficult and reuse even harder.

Also note that MVC is overkill for most rich client GUI work, as a Button is both a Control, a View and a Model. Swing fortuantely hides most of the implementation so you dont need to worry about it. Most other desktop GUI frameworks don't use MVC at all.

Please note architectural layering is a different concept.The end result is that we have J2EE web technologies with very poor encaspulation, making development difficult and reuse even harder.Also note that MVC is overkill for most rich client GUI work, as a Button is both a Control, a View and a Model. Swing fortuantely hides most of the implementation so you dont need to worry about it. Most other desktop GUI frameworks don't use MVC at all.

You are describing JavaServer Faces... one of the reasons for the new JSP 2.1 specification--- and EL alignment, is so JSF and JSP can work more seemlessly together.

Jacob (JSR 252 EG)

Oracle is very active in JSF area. What
message they send by "no vote"? I guess
Nortel and Google also are trying to
communicate something?

Alex V.

If you don't know java don't write jsp :)
We can go on with this forever...JSTL, EL, struts-tag, JSF tags....Tags are an overkill. And sometimes with all the diff versions of these tags you could find yrself in jar hell:)

Scriptlets can be easily bugged if you know java
And I don't think anybody would be writing jsp pages without java knowledge -- a fact:^)

And if you use one of the many MVC implementations...things will be fine.
Maintenance? What maintenance?
I have rarely gone into an interface and made changes once it has flown off into production.
Third party maintenance? Put plain old comments in there...will work

Very interesting thread.

As a JSP co-spec lead, I can say that while wanting to preserve our goal of simplicity, we also acknowledge that the needs of the community evolve, and we're definitely interested in investigating ways to improve the EL. As Jacob mentioned, the JCP process is quite transparent and people can easily voice their opinion directly to the Expert Group.

Please see my blog on the topic.

I also took the liberty to file issues on the constructive comments I could find on this thread. We'll definitely be looking into this. See issues 145-146.

145: Access to constants
146: Access to indexed properties
147: Method invocation

For anyone interested, I'd also encourage you to check the interesting comments we got from Patrick Lightbody. They've been filed under issues 141 to 144.

[Links in my next post. I just can't seem to be able to put them in here].

Keep getting error:
The message body contains invalid HTML, but I do not have any html... argghhh... One more try...

Blog

OK. Looks like I cannot use URLs directly in the message body (although the docs says that bare http addresses will be wrapped automatically).

Here is the list of links related to my original post. Hopefully this will work.

Blog
Access to constants
Access to indexed properties
Method invocation