The number of issues being reported related to expression compilation seems to have gone way down – so it may tentatively be safe to say this feature is “becoming stable”.

The javacc grammar parser code was also re-generated for this recent release using some of the new improvements that Tom Copeland mentions here.

As I’ve not really done a good job posting updates about releases I’ll go ahead and dump the full 2.7 – 2.7.2 jira issue log here as well. The good majority of issues fixed have been related to the expression compiler work – but there is still a lot of good stuff in there that projects using it without expression compilation will still find very useful. (from straight up bug fixes to substantial performance / concurrency improvements and even full Java 5 support for generics and varargs)

Release Notes – OGNL – Version 2.7.2

Bug

• [OGNL-80] – CastCastException when setting properties on objects that use generics in superclass properties
• [OGNL-121] – Race condition in SimpleNode#evaluateGetValueBody(OgnlContext, Object)
• [OGNL-122] – OGNL Double to BigDecimal type conversion
• [OGNL-124] – When OgnlException is wrapped in another exception, any exception wrapped by the OgnlException appears to be swallowed
• [OGNL-125] – When OgnlException is wrapped in another exception, any exception wrapped by the OgnlException appears to be swallowed
• [OGNL-126] – Don’t call setter properly
• [OGNL-127] – can’t find methods with varargs parameter
• [OGNL-128] – remainder expression doesn’t look for child syntax expressions
• [OGNL-129] – Collision property and method with same name
• [OGNL-130] – Array syntax error
• [OGNL-134] – primitive character conversion in statement compilation
• [OGNL-136] – Ignore synthetic methods when using getDeclaredMethods()
• [OGNL-141] – Very serious OgnlRuntime scalability and concurrency bug in versions greater than 2.6.10
• [OGNL-142] – scope=provided on javassist dependency leads to NoClassDefFoundError

New Feature

• [OGNL-7] – Full Java 5 Support for OGNL

Task

• [OGNL-133] – bring back old OgnlContext.callMethod parameter
• [OGNL-137] – Port OGNL docs from ogn.org to OpenSymphony’s OGNL confluence space

Release Notes – OGNL – Version 2.7.1

Bug

• [OGNL-96] – object equality b0rken
• [OGNL-97] – Compile OGNL expressions often require #this
• [OGNL-98] – Simple ognl expressions like comparison “==” or divide “/” cause errors
• [OGNL-103] – Unable to find correct readMethod named is…()
• [OGNL-104] – object equality still broken
• [OGNL-105] – Compiled OGNL using bracket notation requires #this
• [OGNL-106] – Null Pointer Exception when parsing enum constant
• [OGNL-107] – CLONE -ClassCastException in ASTChain
• [OGNL-108] – Console Stack traces when using instanceof in OGNL
• [OGNL-110] – Subtracting or multiplying two doubles causes error in log, though the calculation is correct
• [OGNL-112] – Unable to find getter when multiple getters exist with similar naming
• [OGNL-113] – Object with null toString() causes NPE in OGNL
• [OGNL-114] – fails method name resolution for boolean JavaBean properties

Release Notes – OGNL – Version 2.7

Bug

• [OGNL-6] – When setting fields type conversion returning null falsly reports a NoSuchPropertyException
• [OGNL-9] – Cannot handle hivemind’s messages.format
• [OGNL-10] – Calling methods with parameters containing more calls ?
• [OGNL-11] – ClassCastException in ASTChain
• [OGNL-12] – expression compilation problem
• [OGNL-13] – Class loading issue with in OGNL 2.6.7+ when multiple classloaders
• [OGNL-14] – Ternary expression, NPE
• [OGNL-16] – Unable to parse OGNL expressio
• [OGNL-17] – OR expression compile error
• [OGNL-18] – bad array index selectedPresenters[index]
• [OGNL-19] – expression concatenated via “and” / “&&” is not evaluated correctly
• [OGNL-20] – expressions compilation complains about a null setter body
• [OGNL-21] – another “setter body: null ” error
• [OGNL-25] – Expression stop working in Tapestry 4.1.2
• [OGNL-26] – Try to access to the hidden class java.util.HashMap$Entry
• [OGNL-27] – Bug in new version of OGNL
• [OGNL-28] – CLONE -OR expression compile error
• [OGNL-29] – String concatenation of different types fails in ternary expression
• [OGNL-30] – NOT with OR fails
• [OGNL-31] – Caching problem when looping over different implementations of the same interface
• [OGNL-32] – Contatenation of single character string results in wrong outcome
• [OGNL-33] – problem evaluating an expression on an abstract class not implementing all methods of an implemented interface
• [OGNL-35] – CLONE -expression concatenated via “and” / “&&” is not evaluated correctly
• [OGNL-36] – Another “getter body: null setter body: null ” Error in combination with “||”
• [OGNL-37] – messages.format with 3 parameters causes ArrayIndexOutOfBoundsException
• [OGNL-38] – CLONE -NOT with OR fails
• [OGNL-39] – Ternary expression with date formatting causes Mismatched stack types error
• [OGNL-40] – Error appending strings
• [OGNL-41] – javassist CannotCompileException for Expression ” value || !okOnly “
• [OGNL-43] – getValue() not called on second parameter to && if the first returns true
• [OGNL-44] – Appending a Long, String, and int results in error
• [OGNL-46] – CLONE -Caching problem when looping over different implementations of the same interface
• [OGNL-47] – Using a property from an enum constant as a method argument fails
• [OGNL-48] – ognl string concatenation + static syntax does not render properly
• [OGNL-49] – VerifyError: wrong return type in function
• [OGNL-50] – Nullcheck with && and ! fails
• [OGNL-52] – setAccessible(false) threading bug
• [OGNL-53] – OR fails with boolean expression as first condition
• [OGNL-54] – Calling method of object and passing a ‘conditional’ expression as parameter
• [OGNL-55] – Calling method of object with String parameter
• [OGNL-56] – the NOT of complex expression fails
• [OGNL-57] – The compilation of expressions with negate symbol (!) causes javassist exception
• [OGNL-58] – Ternary that appends multiple types fails
• [OGNL-59] – Target is null for method
• [OGNL-60] – messages.format with one parameter on a component fails
• [OGNL-61] – Method call gets some (javassist?) code fragment passed as argument instead of the evaluated expression
• [OGNL-62] – Boolean property with is() and toggle() methods causes failsafe error
• [OGNL-63] – IllegalArgumentException
• [OGNL-64] – Appending a Long with dot notation, a String, and an int creates failsafe error
• [OGNL-65] – OR expression with && and comparisons causes failsafe error
• [OGNL-66] – Ternary evaluates unused expression
• [OGNL-67] – Invalid Types error for inequality operator (!=) when used in Ternary Expression
• [OGNL-69] – Tapestry Exception with a map object
• [OGNL-70] – CLONE -Ternary evaluates unused expression
• [OGNL-72] – Wrong return type in function
• [OGNL-73] – Ternary evaluates unused expression with date formatting
• [OGNL-74] – Error in ASTProperty when running in JDK1.4
• [OGNL-75] – Ognl Exception source is null for getProperty(null, “mapKey”) when using split on a map
• [OGNL-76] – Iterating over an Object Array in a For causes NoClassDefFoundError
• [OGNL-77] – javassist classname error
• [OGNL-78] – Appending strings in ternary causes failsafe error
• [OGNL-81] – Boolean expression not evaluated
• [OGNL-82] – java.lang.Integer.valueOf() failling in 1.4 jre
• [OGNL-83] – Can’t get object properties returned from Map
• [OGNL-84] – Indexed expressions (“prop[index]“) do not lookup for the getProp(int index) method in the right class
• [OGNL-85] – constructor signature matching problem (int <-> java.lang.Integer)
• [OGNL-86] – use of incorrect expression root object in some arithmetic expressions
• [OGNL-87] – Get an ognl.InappropriateExpressionException when negating a boolean
• [OGNL-89] – expression compilation problem
• [OGNL-90] – cannot create empty list using {}
• [OGNL-91] – compilation problem in case of minus operator
• [OGNL-92] – “incompatible array types” with enum values
• [OGNL-93] – expression compilation problem
• [OGNL-94] – Tacos:Tree does not work with the current snapshot

Improvement

• [OGNL-3] – Allow setter properties to have another return type than VOID
• [OGNL-15] – public abstract Boolean getQuery() vs isQuery()

OGNL is officially the fastest expression language implementation in the world! hooray, and stuff….

There has been such an immense amount of work put in to both of these releases that it doesn’t do them justice to just link to a simple jira change list:

• Performance – The biggest reason for the delay in this release of Tapestry has been in waiting for the new OGNL bytecode compiler enhancements to stabilize. None of this would have been possible without the kind support / dedication of resources by Patrick Lightbody of OpenSymphony/WebWork/Struts2/Selenium/others I don’t know about. Thanks Patrick! The actual performance boost when using this new OGNL version for existing Tapestry 4 users will be like night and day. The numbers are roughly available in the previous post on the subject – but you are looking at something around 6 times faster than the old interpreted mode was capable of doing.
• Memory consumption / More Performance – The ever consuming obsession that has become YourKit has done almost as much for performance and memory consumption that the OGNL bytecode enhancements have. Development mode issues with running out of jvm memory have been eliminated completely – as well as a number of unneccessary memory consumers in various internal portions of the framework. Page/component instances are now pooled by a much more robust / configurable pool implementation that finally allows idle pages / components to be discarded from the pool – thus reclaiming valuable heap space in production applications at non peak times. As for the performance improvements, well – let me just say that if you have used YourKit before then you’ll know what “the only hot spots left are in the servlet container itself” means. It’s damn fast, ok?
• Testing – A common complaint in the past is that the framework hasn’t really been very giving in sharing how it tests components/pages internally. Obviously people like to test things these days so it makes sense to help with that. We’ve refactored things/moved code around some and now have a new tapestry-test library that you can use to help test your Tapestry applications here: http://tapestry.apache.org/tapestry4.1/tapestry-test/index.html .
• Asset caching – What we feel constitutes one of the higher quality image/javascript/resource caching systems available for standard out of the box servlet apps – (even rivaling some servlet containers in many instances) – is also now available. The details of why/how that came about can be read about here. These enhacements do all kinds of nice things for your assets for you automatically – such as gzipping javascript and css resources as well as handling Etag header fields and similar logic – all while appropriately handling all of the various inevitable browser version quirks that constitute the bain of every web developers existence..
• Google rounded corners / drop shadow image services – Since we know many of you will only be lured by shiny baubles (myself included) – we have added a little something extra to entice you with via the very robust image generation services.
• Documentation – We know people haven’t been very happy about this aspect of things in the past. A number of big changes have slowly been happening in this area – the biggest being a great new series of tutorials covering almost all of the common issues you’ll run across in Tapestry 4 development by Alexander Kolesnikov. They can be found here. Many updates/additions/improvements have been made to the overall documentation effort of Tapestry 4 as well whenever we have found any obvious holes. What’s even better than documentation though? Not needing it to begin with. While we have spent a great deal of time updating and adding to the documentation we have also spent a lot of time improving the framework in general and eliminating any obvious quirks that might have previously lead people to wanting more documentation to begin with. We think you’ll find that a lot more of your typical every day tasks will really “just work” as expected.
• Dojo && Prototype/Scriptaculous integration – The bundled version of Dojo provided by Tapestry has been upgraded to the latest 0.4.3 version. (ok, the latest is technically 0.9 but first things first..) This has allowed us to not only get all of the great bug fixes / improvements made by the team but also to take advantage of the new layered build system developed by James Burke of AOL. The layered build system has increased the speed of the overall page load time of any given page substantially and we are very happy/thankful for his awesome work in this area. This version also features integration of the latest versions of Prototype/Script.aculo.us libraries and the requisite component that uses them which has been named “Suggest“.
• Ajax / JSON Support – Second only to the performance improvements has been the amount of work put in to refining and improving the Tapestry AJAX/JSON support. Client side profiling / performance improvements have overall also been substantially improved. New documentation has been added covering various key areas of this portion of the API as well as some new naturaldocs generated apidocs for our client side javascript library. I don’t feel bad in saying that Tapestry 4.1.2 probably represents one of the most robust java web framework libraries available for AJAX applications in the open source java world today. We’ve been doing this for a really long time now and kind of have this area covered. Show me something that does as much as Tapestry does while also being flexible / debuggable enough to allow you to easily branch off and do things your own way and I’ll concede defeat. Until then….it’s well worth checking out if you haven’t tried this particular side of Tapestry yet.

What does this mean for the good majority of people? Absolutely nothing! (though absolute neitz sounds better)

That is to say, unless you are integrating it into a framework of some sort it is highly unlikely you’ll find any benefit from using it as you won’t get the fancy new compilation features unless you use some of the new API calls. Of course I’ve done the first round and have it officially integrated into the mainline Tapestry 4.1.2-SNAPSHOT releases so you can get some benefit from it if you happen to be using that framework.

I have found some “unfortunateness” with some of the javassist api. Namely a lack of support for generics as of the latest 3.4.ga version I’ve been working against. It looks like I may actually need to sit down and give asm a little test run to see if it fits my needs as was suggested previously by Eugene && Bob. This makes me none too happy, though I hope to be able to take this new knowledge and use it to rip javassist out of Tapestry so that we can support generics properly there. (even though I’ve added a sort of impure/bastardized version of support for this already)

OGNL Future

Ok, so maybe I’m starting to enjoy some of this work a little more than I was at first now that things are stabilizing a little. As such I plan on implementing a few more features Drew had previously mentioned wanting to see happen (as well as a few of my own / whatever others need):

• Separation of 1.4/1.5 API so that the introduction of “Type” in generic form as well as the impact that has on the enhancements codebase can be clearly separated as much as possible. (I’ll probably be taking another look at TestNG for inspiration on doing this properly)
  
• Replace javassist with asm.
• Refactor/replace OgnlRuntime with a more IoC friendly version that can be controlled in such a way that multiple instances can live together in the same VM without issues related to static constructs..
• Introduce a couple new grammar rules for things that look neat, like Howards work on Tapestry 5 and the introduction of the “0…N” loop . (that’s right, a grammar change – I’m looking at you mvel …..)
• …..? Not sure what else is missing.

Much like Tapestry-Prop, the new set of OGNL enhancements rely on javassist to do incremental bytecode compilation / translation of your ognl expressions into their pure java equivalents. There are still plenty of kinks being knocked out here and there, but overall the changes are finally starting to form into something that might actually be usable.

I’d like to be able to take credit for it myself – but the reality is that Drew had already started a lot of work doing exactly this, so I just continued on where he stopped. (using knowledge gained while doing javassist work on Tapestry )

I know people really like seeing performance metrics, so here’s what I’m getting back now from a couple basic expressions:

===================================================================

Constant: 100 + (20 * 5)
       java: 2623089 iterations in 1500 ms
   compiled: 2559264 iterations in 1500 ms (1.025 times slower than java)
interpreted: 2590897 iterations in 1500 ms (1.012 times slower than java)

Single Property: bean2
       java: 2648322 iterations in 1500 ms
   compiled: 2622987 iterations in 1500 ms (1.010 times slower than java)
interpreted: 1816261 iterations in 1500 ms (1.458 times slower than java)

Property Navigation: bean2.bean3.value
       java: 2634885 iterations in 1500 ms
   compiled: 2595186 iterations in 1500 ms (1.015 times slower than java)
interpreted: 538238 iterations in 1500 ms (4.895 times slower than java)

 Property Setting with context key: bean2.bean3.nullValue
       java: 2638050 iterations in 1500 ms
   compiled: 2622542 iterations in 1500 ms (1.006 times slower than java)
interpreted: 563363 iterations in 1500 ms (4.683 times slower than java)

Property Navigation and Comparison: bean2.bean3.value <= 24
       java: 2674087 iterations in 1500 ms
   compiled: 2622686 iterations in 1500 ms (1.020 times slower than java)
interpreted: 517796 iterations in 1500 ms (5.164 times slower than java)

Property Navigation with Indexed Access: bean2.bean3.indexedValue[25]
       java: 2672025 iterations in 1500 ms
   compiled: 2583340 iterations in 1500 ms (1.034 times slower than java)
interpreted: 329001 iterations in 1500 ms (8.122 times slower than java)

Property Navigation with Map Access: bean2.bean3.map["foo"]
       java: 2572917 iterations in 1500 ms
   compiled: 2509147 iterations in 1500 ms (1.025 times slower than java)
interpreted: 404174 iterations in 1500 ms (6.366 times slower than java)

Property Navigation with Map value set: bean2.bean3.map["foo"]
       java: 2543566 iterations in 1500 ms
   compiled: 2545064 iterations in 1500 ms (0.999 times faster than java)
interpreted: 409172 iterations in 1500 ms (6.216 times slower than java)
===================================================================

This is the direct output from an ant console run, so sorry if the formatting isn't ideal.

If you are wondering if / when this will be released, I really don't know. All of the changes made so far have been local to my machine only - but if the patches are accepted then I'd optimistically expect a new maven2 snapshot version of it released sometime this week.

The new changes have also been integrated / tested with Tapestry 4.1.2 already, we're just waiting for the right infrastructure to show up to commit the changes to. For an example just hit the standard Tapestry demo page, everything there is running on the new code already.

http://tapestry.apache.org/tapestry4.1/demos.html