Vodopad, год назад мы ощутили, что инфраструктура JavaEE реально 'over-abstracted', для малых и средних проектов, в итоге это вылилось в создание двух фреймворков, одного для UI, другого для persistance. Оба фреймворка основаны на идеях Ruby on Rails и уже обкатаны на довольно крупном проекте, со средней сложностью бизнес логики. Скорость обучения - день, два для базового понимания, ну и недельку чтобы основательно врубится, скорость разработки - очень высокая.

Итак фреймворк для UI - ActiveWeb( http://code.google.com/p/activeweb/) - по аналогии с Ruby On rails - основан на 'convention over configuration' и паттерне MVC. Центром всего является контроллер, к примеру BookController, который мапится на URL context/book, если вам нужно вызвать определеный метод, просто пишете a href="context/book/method" при этом будет вызван метод method у BookController, внутри метода можно удобно получить входные параметры, положить в контекст какие то выходные данные view("book", new Book()), после выполнение метода автоматически отрендерится темплейт /views/book/method.ftl. Для рендеринга мы приспособили FreeMarker, страницы это по сути html - с вкраплениями if(${book}) ... else ... итерацией коллекций и т.п.. то есть по сути ваша страница - это обычный html с вкраплениями данных, которые вы положили во view во время выполнения контроллера.
Фреймворк полностью поддерживает REST, также очень хорошо поддается тестированию при помощи специального фреймворка, также реализовано Dependency Injection при помощи легковесного фреймворка Google Guice. Несмотря на то что все основано на соглашениях, существует множество аннотаций, чтобы переписать дефолтное поведение для нестандартных случаев. Если использовать в качестве persistance ActiveJDBC, то кода приходится писать на порядок меньше, чем в случае Spring/Hibernate

Итак, пару слов о ActiveJDBC( http://code.google.com/p/activejdbc/) - это персистенс фреймворк, также основанный на соглашениях, и который имплементирует паттерн ActiveRecord, по сути все entities - это подклассы activejdbc.Model, бизнес-логика содержится либо в статических методах Book.findById("name = ?", bookName), причем findBy.. наследуются от Model, как и многие другие методы, вроде save, update ...или с помощью методов эземпляра. По умолчанию entity Book мапится на таблицу books, все поля хранятся в мапе и имена полей совпадают с именами колонок в таблице, по сути код вроде Book extends Model - часто довольно полная имплементация вашей сущности :)
Фреймворк поддерживает Lazy-loading, caching, все виды ассоциаций(one-to-many etc..), батч-операции, транзакции, локинг, валидацию, каскадность, возможность легко писать тесты, листенеры на onSave onDelete... и т.д. Наследование реализуется через полиморфные ассоциации, немного неудобно но это недостаток самого ActiveRecord. Есть встроенная поддержка миграций(просто кулл). В общем много всего вкусного. Конечно есть недостатки - время от времени фиксим баги, а также для того чтобы Model работала, приходится инструментировать код, но это разумный компромисс, есть подробные инструкции на сайте, что со всем этим делать.

По итогу, на нашем проекте, когда мы сами контролируем базу, и логика не то чтобы очень сложная - скорость разработки просто феноменальная, плюс в отличие от Ruby - фреймворки соответствуют стандартам JavaEE, и естественно могут быть синтегрированы с любым java -кодом.

Есть еще альтернативы, вроде Play фреймворк и Grails, тоже советую посмотреть, но в каждом мы нашли небольшие недостатки, но я думаю вам будет из чего выбрать:)

авторзабыл ник,
У RAD для ГУИ ещё нужны компоненты-контролы типа Грид\Дата\Плеер\График

Да, согласен. Но большинство фреймворков для rich UI - это крест на хорошем дизайне, или большой геморрой с оным. Сейчас в обилии javascript виджетов, которые элементарно встраиваются в приложение, как-то так.

авторзабыл ник,

безумно отличается от SpringMVC+чтоугодно.

авторМде, попахивает конкретным велосипедированием.
По вебу - все это уже давно есть в Spring MVC.
ActiveJDBC - не видно какиз-либо преимуществ над Hibernate/iBatis.

Короче говоря - зачем это все?

Да, в ваших словах есть зерно истины, и довольно весомое. Насчет Activeweb - он основан на идеях как раз-таки Spring MVC(правда второй версии) и ROR. Да, в Spring MVC 3, как раз большинство наших идей и было реализовано, и сейчас не настолько актуально. Могу только добавить, что тестировать ActiveWeb проще, и практически не надо никакого конфигурирования, все работает по convention, что заметно ускоряет разработку. Ну и если в качестве персистенс выступает AJ - то AW идеально с ним интегрирован.

Теперь про ActiveJDBC - какие у него преимущества? Да те же самые что у паттерна ActiveRecord перед Unit of Work. Естественно это не панацея, но иногда Хибернейт - это из пушки по воробьям. Разберу на примере, что вы делаете когда пишете код по работе с сущностью Book,
1)Настраиваем единоразово логику получения коннекшенов, транзакции и т.д( ну там persistence.xml и прочая шляпа)
2)Создаем класс Book, мапим его на базу, по сути 100-200 строк dumb кода из аннотаций и геттеров.
3)Создаем DAO, опять же 100 строк примитивного кода, хотя опять же есть тенденции к уходу к GenericDAO, но не суть, факт в том, что еще один класс.
4) В каждом контроллере инжектим PersistenceContext, в методах вызываем em.persist(book) и т.д. - опять лишние строки

Что происходит в AJ -
1) В DBConfig указываем jndi датасорса, потом при каждом реквесте вызывается фильтр который берет коннекшен из пула и ложит его в ThreadLocal, в конце реквеста - возвращает в пул.
2) Просто пишем Book extends Model
3) В контроллере вызываем b = Book.find("author=?", author): b.set("date", new Date()); b.save();

Итого - в хибере, 300 строк в общем то однообразного размазанного кода + конфигурация, в AJ - ну строк 15, учитывая что такие фичи как ассоциации, лейзи лоадинг, интерсепторы и т.д остаются досупны.
Да, я никого не уговариваю всем срочно бежать переходить на AJ, но раз топик стартер хочет RAD и любит ROR, то наше решение вполне должно его устроить. Хотя надо прекрасно понимать недостатки Active Record и границы его применения. На мой взгляд, для среднего проекта, и когда доменная модель хорошо ложится на базу - очень достойный вариант.

Чем лучше iBatisа? - тем что ActiveRecord - это разновидность Rich Domain Model, сущности с поведением, в отличие от простых холдеров колонок из определенной таблицы, + практически нет никакой конфигурации.

Не знаю как вы, но лично я устал от излишней сложности java, там где без нее можно обойтись.
В общем, как-то так. Мой вывод таков, что данная связка подходит далеко не ко всем проектам, но если вписывается в концепцию - то очень сильно уменьшает время девелопмента, чего и хотел ТС

авторзабыл ник,
ну. если без ГУИ, то это конечно RAD/2.

Ну на самом деле FreeMarker теги пишутся элементарно, аналог кастомных тегов jsp, в рендерер запихиваешь value, он тебе итерирует таблицу и отрисовывает все что хочешь. У нас в проекте реализованы datePicker autocomplete и еще пару виджетов. В стандартный бандл не включены, ибо не так сложно самому написать, плюс на примере richfaces стало ясно - когда пытаешься учесть все - то получается что не уголишь в итоге никому. Есть идея на странице проекта выкладывать рецепты кастомных тегов.

автор- Rich Domain Model полностью с БЛ в одном слое-классе? А как\что на клиента отправляете. Т.е. сериализация?

Именно, на клиента отлается html, xml, json и т.п, у Model есть методы toJson, toXML и тп. в контролере можно сделать обратное преобразование - Book b = Book.fromParams() Book.fromXml(). По сути поддерживаются только тонкие клиенты, ибо как говорилось уже коннекшн лежит в ThreadLocal