Users of "low-slung" scripting-based web frameworks (such as PHPs, Perl, and Ruby on Rails have traditionally had all the fun. These people are used to having half of an app coded and working in about the time it takes a Java developer to fire up their favorite 200Mb development environment (**cough**Eclipse**cough) and have slick and well-developed PR engines (check out those sites above) that happily thumb their noses at the awkwardness and pain suffered by those on the other side of the fence.

That so many developers continue to persist with more heavyweight Java (and not to say C#, etc.)-based webapp solutions is testament to the fact that the technical arguments remain compelling. Mainstream programming languages offer a robust, well-developed toolset, programming idiom, and libraries that promise the highest performance and maintainability to the apps created by developers who can use them correctly. Unfortunately, historically, the toolset and technologies offered on this side of the fence have been so awkward, fragile and perplexing that webapps created in Java can frequently end up being the butt of humour aimed at their bloatedness and poor performance, unless they are wielded with nigh-surgical precision. The worst aspect of this situation is the near-impregnable barrier between the two communities. Scripting-based webapps offer an extremely fast and accessible start, and end up being the playground for a great deal of inventiveness displayed by users and communities that simply haven't the time to invest in becoming programmers - BUT set these users up for an extremely nasty surprise once their app gets to the maximum complexity their solution can support. A "scripted" app that reaches critical mass will simply implode, with no migration path left to developers that may be called in to evolve it to the next level of robustness - development will pretty much have to begin again from scratch in, say, converting an unwieldy heap of PHPs into a high-performance, scalable and maintainable J2EE solution.

One of the core aims of RSF is to create a "Royal Road" allowing apps to evolve from simple "live-tested" prototypes through to an end-of-life as a developer-maintained, Spring-configured behemoth.

One of the most compelling arguments for Java as a platform in recent times has been the creation of Hibernate and a breed of similar "zero-intrusion" ORM solutions that promise to allow Java developers to keep their hands clean of SQL, while dealing with persistence in a Java-only world. TheServerSide recently ran a very insightful commentary which highlighted the many reasons why an application based on Hibernate was very much more likely than a Rails-based solution to avoid foundering on the many rocks of scalability, maintainability and incoherence - but the fact remains, using Hibernate in current Java web frameworks is extremely awkward . In fact, the Hibernate team have been observed remarking that Java web frameworks amuse them greatly, and wondering why it is that integration with Hibernate always seems to involve so much more than the "like 10 lines of code" that it should require.

Well, the time for general nose-thumbing from script-writers and Hibernators alike is at an end, since we present here - the Hibernate Cookbook. Following the great tradition of example theft started by the NumberGuessing app, this example is also stolen - this time from the Ruby on Rails camp. In this example you will not only see Spring, Hibernate and HTML working together without anyone treading on anyone else's toes, you will also see this Java-based RSF example written without any Java code written whatsoever.

Yes, that's right - if the thought of firing up a big IDE festooned with little icons and knicknacks gives you the heeby-jeebies, you can rest assured you can get through the development of this app with nothing more than command-line tools - you will need Maven, Tomcat and a JDK installed, together with your choice of database (we will use MySQL as in the Rolling with Ruby on Rails (ROR) example).

While we cannot promise "ten times faster development", I hope you will agree that the development gap between Java webapps and the script crowd has been considerably narrowed.