{ Make this readable }

Wednesday, October 10, 2007

Expression Languages (OGNL and MVEL)

For those of you using Expression Languages in your programs to add that bit of pluggable logic fragments, I'm sure you've evaluated or probably even use OGNL. StreamCruncher uses OGNL 2.7+ to handle some of the messier parts of Expression evaluation and I've found it to be a huge time saver. What's even better is that the 2.7 version also converts the Expressions into dynamically generated Bytecode.

So, if you want to evaluate OGNL, here is a list of useful links. They are not easily locatable, so I thought this would also be a good place for me to bookmark them for future use.

Here's the old link - OGNL
The 2.7+ versions are handled by this guy Jesse - his Blog
The latest releases - on OpenSymphony

I also strongly suggest evaluating another very well done Expression Language - MVEL,which is written by Mike - his Blog

4 comments:

Mark Proctor said...

We use MVEL in Drools, we evaluated OGNL and there is simply no contest. Although admittedly we had a lot of input in the design to ensure easy embed ability. for 400kb you get:

-Debugging symbols, as used in the Drools debugger.
-High performance reflection mode, as well as JIT.
-Great templating
-Dynamic mode and Strict type mode with full type inference.
-Macro processor
-In-line interceptors
-Not just expressions, can do code blocks too.

Mike is branching MVEL now to start on MVEL2.0 and has some kick ass stuff planned. The other thing is Mike is very committed to the language and encourages active participation in the design process, he's quite literally made much of the features at our request and to our spec. He generally jumps on bugs and issues within hours if failing unit tests are provided. OGNL on the other hand is mostly unmaintained the bytecode stuff was a quick hack, and done with a bad api, just to try and stop MVEL's rise - apart from that its not done much in years.

http://mvel.codehaus.org/

Mark Proctor said...
This comment has been removed by the author.
Ashwin Jayaprakash said...

I agree. I liked MVEL for its elegance. But I had already started off with OGNL.

One thing I noticed (correct me if I'm wrong) was that MVEL does not compile your expressions into type-specific code. It kind of stops in between fully compiled code and interpreted AST.

I saw that in OGNL, to compile an expression, I had to provide all the exact data types before hand. But MVEL would "compile" arithmetic expressions too, even if all the methods just returned generic Objects instead of Integer, Float etc. I think that was why MVEL was slightly slower than OGNL. But all the other features in MVEL would simply outweigh OGNL's speed.

Mike Brock said...

"But MVEL would "compile" arithmetic expressions too, even if all the methods just returned generic Objects instead of Integer, Float etc. I think that was why MVEL was slightly slower than OGNL. But all the other features in MVEL would simply outweigh OGNL's speed."

Well, yes and no. MVEL does something called optimize/dynamic de-optimize, where in some cases it will just compile type unsafe bytecode based on what it sees at runtime.

If something goes wrong in the future do to an object of a different type (from what was compiled by the optimizer), MVEL will revert to reflection and then re-optimize.

The slight difference in speed from the point of view of MVEL and OGNL has more to do with MVEL's lightweight wrapper around the emitted bytecode in order to ensure type consistency (and dynamic op/deop).

In theory, MVEL could get the same benefit with it's generated bytecode if you wanted to go through the gymnastics of extracting the inline generated classes and then calling them directly (which is what OGNL 2.7 makes you do).