Ed Burns's Blog

The case for EL in Dolphin

The case for EL in Dolphin

If you're well connected to the JSF and Web Tier world, you'd know that the Expression Language used in JSF and JSP in Java EE 5 is slated to become a separate JSR. It is my hope, and the hope of several others, that this JSR be moved into the core JDK in the Dolphin timeframe.

I'd like to use the comments on this blog entry to gather use cases to justify the inclusion of the EL into the core JDK. I'll start off with some use-cases of mine, and some I collected from ##jsf.

• Make it easier for different frameworks, notably web frameworks, to interoperate

• Make it easier to write frameworks.

• Make performing Inversion of Control easier, reduce complexity of frameworks using IoC. IoC is not just for server apps. It can benefit desktop apps as well (look at Spring Rich Client).

• Be the underpinning of how Beans Binding links are specified.

• Could enable a markup based UI descriptions in Swing and allow for easily specifying links between ui components and their data models.

• Desktop applictions also have the notion of scope, but it goes beyond the normal "request/session/application", and it tends to be more specific to the application requirements itself. For example, when doing a sub-dialog, you're really entering into a scope. It would be nice to have a place to store model objects in that scope that would automatically go away when the dialog is dismissed. EL is a good way to do that.

Any others? I'm sure I'm just hitting the tip of the iceberg here.

Comments

• Awesome! Java being better everyday!

  Posted by: rpa_rio on August 15, 2006 at 10:08 AM

• 
  How about cases to not include it?

  Feel free to promote the JSR. I encourage and support the EL as a valid tool for all sorts of applications.

  However, if it is to be implemented, then it should be implemented and aligned with Java using the Scripting API that Javascript is going to use. It should be as easily interfaced as any other scripting langauge, because, while limited, that's all an EL is.

  On that note, the JDK already will HAVE a scripting language, and that language is Javascript. That's water under the bridge for the "anti-bloat" JRE crowd.

  But there is no technology argument as to why the JSP EL should be bundled as part of the JDK rather than simply downloaded and installed seperately.

  One can argue that Javascript was put in as an example case of how to use the Scripting API. That was one of the points for bundling JavaDB in the JDK -- an example of JDBC 4.0. In that case, we certainly don't need another example by bundling EL.

  Why does EL get special recognition as Yet Another scripting language suitable for bundling in the JDK over and above any other of the plethora of scripting languages available for Java?

  EL already comes with JEE, where it is used extensively.

  Rather, Sun should simply promote and market EL outside of the JEE space, provide simple example code suitable for folks to use to make EL "plug and play" in to their own applications through the scripting API, and be done with it.

  It doesn't need to be in the JDK.

  Posted by: whartung on August 15, 2006 at 10:49 AM

• the scripting api that was included in the JRE is overly primitive compared to EL, IMHO-- API wise only-- i do think there should be JavaScript implementations of the EL-api or even OGNL implementations.

  Posted by: jhook on August 15, 2006 at 11:56 AM

• JSR-303, Bean Validation, is going to be a JSE spec, not JEE, and it could definitely make good use of the EL. It would be useful for getting property values (including nested subproperties, etc.) and calling methods to check values. It would be great for an expression validator, like the one we use in WebWork, which lets you define a bit of EL to do more complicated comparisons.

  Posted by: jcarreira on August 15, 2006 at 01:08 PM

• Dolphin = MySQL?

  Posted by: phlogistic on August 15, 2006 at 04:14 PM

• So for those of us that have no idea what Expression Language is or how it can be used, is there a good link or reference we can go to?DB

  Posted by: dblair on August 16, 2006 at 11:10 AM

• I strongly agree with whartung: the EL is not suitable for broad inclusion. In fact I was deeply saddened to see it accepted even to its current status - it is woefully inadequate and way too primitive compared to some other binding solutions (especially compared to mechanisms in other languages and frameworks, which many JSR implementors seem to be woefully ignorant of). It's slow, bloated, has confusing context handling and is generally not suitable as generic high performance glue, with maybe the sole exception of its role as band-aid for the terrible JSP "technology" that should have been killed years ago too. :-(
  

  Posted by: holgerhoffstaette on August 16, 2006 at 11:34 AM

• @holgerhoffstaette

  I too used to think that JSPs sucked. Now that I'm using tools which have pretty good JSP support (syntax colouring, auto-indentation that works 50% of the time, auto-completion in the scriptlets). They don't seem so bad anymore.

  Probably the auto-completion one was the most important, since JSPs have a bunch of 'invisible' variables which may or may not be in scope at any particular time.

  For instance, I'd still much rather declare a variable in a scriptlet than use the jsp tag for using a bean. The tag is braindead, because it is more effort than that which it replaces.

  Actually, that applies to a lot of the XMLish technologies. The problem is the slippery slope... we want to do configuration in xml, then we want to do something a little tricky - so we have to build in logic and conditionals into the XML...

  But programming in XML blows goats.

  So now we build big tag libraries to enable this... but it still is way too ugly, so we invent and embed some other language inside the XML...

  Hence the EL.

  Now to my question: If the EL is not Turing Complete, then why not? And if it is Turing Complete, then why on earth are we embedding one Turing Complete language inside another???

  Is the compelling 'use case' data binding? Gluing different components together?

  And yet... as an object oriented language, Java is already all about gluing different objects together! It should already be sufficient to solve this problem!

  If you were writing the JSP as a servlet instead, would you ever need to use EL??? Seems like a problem in search of a solution to me.

  Posted by: rickcarson on August 16, 2006 at 04:16 PM

• I completely agree with its exclusion. Exactly what problems is expression language solving for the general JDK? It might have been used for the web technologies, but that's a very specific field, serving very specific purposes. I think most developers feel very comfortable calling it what it is; a simple language for front-end web convenience.

  If you want scriptability, look to a mature scripting language, not something that was born out of that need.

  Also agree, non-type-safe stuff like EL really doesn't need to be the only solution to XML, and it makes stuff annoying. I *HATE* debugging JSP EL errors due to it's ambiguity and "where did the error really happen"-ness. Please do not push this towards the front of the Java platform.

  I'd rather work in Python/Javascript/TCL.

  Posted by: ilazarte on August 16, 2006 at 07:05 PM

• Just a note, I have worked in several large scripted environments, and let me say, EL simply wont cut it, do *not* try to make this a general purpose "helper" language to Java, it wont work in the long run.

  Posted by: ilazarte on August 16, 2006 at 07:07 PM

• why wont work?
  EL seems to me really suited in MVC, web or not web.

  Posted by: agoria on August 18, 2006 at 04:21 AM

• 
  Ed, EL has to compete with SQL, JXPath, OGNL (and even LINQ, drools and Prolog) and all the faults people find with all of them. I hope it's a long road to broad acceptance in Java, so that we get some time to kick the tires and shake out the problems. We didn't get that for JavaDB. I've heard no one ask, "Why not just pick up HSQLDB instead?"
  

  Posted by: dwalend on August 18, 2006 at 05:42 AM

This work is licensed under a Creative Commons License.