The Apache Tapestry project released a preview of Tapestry 5.0, a major update to the popular Java Web application framework.

Web application development with Tapestry centers around the page metaphor, representing pages and page links as objects and their interfaces:

Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java code. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects—and specifically not in terms of URLs and query parameters...

A major new Tapestry 5.0 feature is use of Java POJOs and annotations in place of XML as the configuration language for Tapestry applications:

Components are pure, simple POJOs... Tapestry no longer uses XML page and component specification files. Information that used to be supplied in such files is now supplied directly in the Java class, using Java annotations.

Tapestry 5's API is based almost entirely on annotations. You will annotate classes to indicate that they are components, you will annotate fields to allow Tapestry to maintain their state or to allow Tapestry to inject resources, and you will annotate methods to tell Tapestry when and if a method should be invoked.

Tapestry makes the development process easier by reloading all changed resources automatically. That includes changes in application templates as well as changes in Java classes:

When a template changes, all page instances (as well as the hierarchy of components below them) are discarded and reconstructed with the new template... A future version of Tapestry may be more selective, removing only page instances that are affected by the changed file(s)...

On a change to any class inside a controlled package (or any sub-package of a controlled package), Tapestry will discard all page instances, and discard the class loader... Persistent data on the pages will usually not be affected... This allows you to make fairly significant changes to a component class even while the application continues to run.

Performance improvements are another feature of Tapestry 5:

The new code base operates considerably faster than Tapestry 4. Critical code paths have been simplified, and the use of reflection has been virtually eliminated. Tapestry 4 was as fast as an equivalent Servlet/JSP application, Tapestry 5 is much faster.

Tapestry are inherently scalable, according to the project documentation, due to Tapestry relying on relatively little application state:

In Tapestry, the structure of any particular page is static. This is necessary for several reasons, most importantly because Tapestry pages are pooled. Creating a Tapestry page is an involved process, because the page object is simply the root of a large tree of other objects including user provided components, many kinds of structural objects, template objects, and others. Creating a new page instance for each request is simply not scalable... Instead, Tapestry pools pages.

Tapestry does not need to store page instances inside the HttpSession. At most, it stores a smattering of persistent field values from the page, but not the entire page instance... This lean use of the HttpSession is key to Tapestry's very high scalability, especially in a clustered configuration.

What do you think of Tapestry's approach of modeling pages and their interactions as a tree of interrelated objects?