Vote to release Tapestry 3.0

Just submitted a vote to release Tapestry 3.0 FINAL. Quite a few people have been demanding a release (yes, that means you, Erik) and I think Tapestry is in excellent shape to proceed forward. Not quite all my goals for 3.0 have been reached ... there's still some gaps in the documentation, and the test suite isn't quite at the level of code coverage I'd like (it stands at 81.3% overall, and should be in the 85 - 90% range). Regardless, Tapestry 3.0 is stable and more than ready for production.

The vote will run into Saturday, with an announcement following on Monday. There's a chance that one of the committers will decide that a bug is too important to wait, and will veto the release.

The team in general, and myself in particular, have really big plans for release 3.1. Everyone's hot button item is modularity ... in 3.0, all your page specs go in WEB-INF and all your page templates go in WEB-INF (for some people) or in the root folder (for me). That causes two problems. First, those directories can get crowded when you have dozens or hundreds of pages (especially when you add in messages files and other assets to the mix). Secondly, J2EE prefers that you split your application across folders, because it (effectively) applies declarative security at the folder level. Therefore, you want to be able to put all your administrative pages, with access restricted to an admin group, into an admin folder.

This will require a bit of a rethink on how Tapestry generates and interprets URLs, and likely, some significant changes to the IEngineService interface.

The other significant change relates to component parameters; I would like to deprecate directions "in", "form" and "custom" and always use (the equivalent of) direction "auto" ... but add in hints that determine how long values can be cached. That is, once you evaluate an OGNL expression, is the value valid just while the component renders, until the page finishes rendering, or until the end of the request? I have a rough mental outline of how this all will work, and it's going to be a lot of fun with Javassist. Components will have to know when they start and finish rendering, whether parameters are bound, whether they are bound to invariants or to expressions and so forth.

That, combined with Drew's upcoming improvements to OGNL should be very exciting. Mind Bridge has profiled Tapestry applications and they can spend around 50% of their time evaluating OGNL expressions. The majority of those OGNL expressions are simple property references. They're working on a plan to make use of Javassist to replace reflection with direct method invocations where appropriate, and Drew's seen about a 10x improvement.

This leads me to the following prediction: In Tapestry 3.1, Tapestry applications will be significantly faster that servlet, JSP, Struts or JSF applications with equivalent functionality. Of course, it's pretty much impossible to find applications with "equivalent functionality", but none the less. By improving the efficient of OGNL, and making use of the optimizations possible because of the Tapestry component object model, I believe the overall processing (especially with respect to Java reflection) will decrease noticeably.

Now if I only had my own personal performance lab ...