One of the big advantages of the scripting approaches to Web development (including JavaServer Pages at one extreme, and Ruby on Rails at the other) is the velocity of change: you can change a source file (a JSP, a Rails template, or even a Rails class) and see the change immediately.
Tapestry has traditionally been more aggressive at caching. Once a template or a XML file has been loaded into memory, it's stuck there. During development, you can use the -Dorg.apache.tapestry.disable-caching=true trick to turn caching off, but this not only slows down every request, but includes a memory leak that will eventually tank the application. It also does not reload classes the way it reloads templates and XML files.
In my quest to create a Java web development environment as compelling as Rails, one of the first things to tackle is this aspect of development: effective and efficient reloading of component classes.
The first pass at that code is now in the repository. Component classes are loaded in their own class loader (this is also necessary for the Tapestry AOP code that transforms classes as they are loaded into memory). When any transformed classes are changed externally, the class loader, as well as all instances derived from those classes, are discarded and a new class loader is created.
This will work quite well, far better than Tapestry 4's development mode. In production, you'll just throttle down how often Tapestry checks to see if underlying files have changed.
What's interesting is that I've been working, off and on, on this code base since mid-February. This compares to how long I spent on the initial prototype of Tapestry way back in January 2000, where I spent a couple of weeks of furious coding just to get to a simple "Hello World". In those couple of weeks, I "invested" Tapestry with many of the features that would grow with it, and support that growth, over the intervening years: the component hiearchy, the original and primitive form of templates, component parameter bindings, page loading, external XML page and component specifications, and other things long forgotten. To me, it was like winding up a spring ... all that upfront effort paid off with a basic design that was "right enough" to keep Tapestry innovative for many years.
The reason I'm starting with a new code base for Tapestry 5 is that it's time to wind up that spring again. The couple of design errors, only apparent after the fact, in Tapestry 4 are all but insurmountable without a fresh start (this primarily includes the requirement to extend base classes, but there are many more subtle things that need addressing). Further, the fact that I've spent a chunk of time getting the basic class loading and AOP support in place, the fact that anything web application is still weeks or months off, is actually a Good Thing. The spring is going to be wound nice and tight, full of energy for years to come.
In something that was a bit of a surprise, even to me, Tapestry won a Duke's Choice award for innovation at this years JavaOne.
