Не так давно я задавал вопрос в Groovy mail-list — есть ли какой-то устойчивый список вещей, которые надо избегать при написании высокогопроизводительного на Groovy. Среди прочих советов, один из главных разработчиков Groovy, Jochen «blackdrag» Theodorou указал, что в общем случае, зачастую использование конкретного типа при объявлении переменной (например, MyType var =… вместо def var = ...) может ухудшить производительсть из-за накладных расходов на проверку типов и, если нужно, их приведение.

По утвеждениям разработчиков Groovy, многие из проблем в этом области наблюдались в версиях вплоть до 1.7 и были затем исправлены во время большой работы по общей оптимизации рантайма, проделанной в версии 1.9. Ниже, однако, небольшой эксперимент, который показывают эти накладные расходы даже на Groovy 1.8.3.

Перед этим экспериментом будет полезно просмотреть следующую статью — groovy.codehaus.org/From+source+code+to+bytecode, где рассказывается про то, как по шагам исходный код на Groovy преобразуется в байткод JVM, а так же почитать какую-нибудь вводную статью в собственно байткод, например эту — www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/.

После года разработки и трех релиз-кандидатов команда SpringSource презентовала новую версию веб фреймворка — Grails 2.0. Я часто использую Grails в своих проектах и внимательно слежу за процессом разработки и выпуска новых релизов.

Интересно заметить, что изначально релиз планировался под версией Grails 1.4, но фундаментальных изменений оказалось слишком много, и Grails присвоили версию 2.0.
Итак перечислю, что нового появилось в новой реинкарнации Grails:

Зачем нужен deploy-скрипт

Grails-приложения очень легко собираются в WAR. Делается это так:

grails war

Помимо того, что WAR собирается, очень хочется этот WAR еще и установить на сервер. В нашем случае это Tomcat. Установка вручную требует некоторой возни:

1. Остановить сервер. Убить процесс, если он не остановился сам.
2. Удалить старые файлы приложения (на всякий случай)
3. Скопировать новый WAR на сервер. Иногда его нужно переименовывать (скажем, в ROOT.war)

В Maven эту работу может проделать, например, cargo plugin. Но с ним много приключений и настройки, причем он не особо учитывает особенности сервере.

Мы также можем использовать shell-скрипт. Но зачем писать на неудобном языке shell, когда есть замечательный кроссплатформенный язык Groovy?

Groovy — объектно-ориентированный язык программирования разработанный для платформы Java как альтернатива языку Java с возможностями Python, Ruby и Smalltalk.

Groovy использует Java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками. Язык может использоваться в любом Java проекте или как скриптовый язык.

Возможности Groovy (отличающие его от Java):

— Статическая и динамическая типизация
— Встроенный синтаксис для списков, ассоциативных массивов, массивов и регулярных выражений
— Замыкания
— Перегрузка операций

[http://ru.wikipedia.org/wiki/Groovy]

Более того, почти всегда java-код — это валидный groovy-код.

«Отгремел» ADD-2011 (кстати — огромное спасибо организаторам — было круто и интересно!) как пора паковать чемоданы на следующую. К удивлению — поиск по «JEEConf» ничего не дал на хабре (или я плохо искал?) — а конференция выглядит очень интересной!
Итак — возьму на себя смелость сделать неофициальный анонс JEEConf — надеюсь еще не поздно.

В продолжении темы маленьких скриптов на groovy — еще один.
Предыдущие: Большие письма в Gmail, Упражнение на сложение (LATEX)

Новый скрипт показывает основы работы с XML и базой данных в Groovy. В качестве задачи выберем сохранение нашей уютной ЖЖшки из XML в базу данных.
Зачем это делать? — SQL нам расскажет всё о нашем (или чужом) ЖЖ — темы, комменты, таги — насколько фантазии хватит собирать статистику

Сначало нам надо скачать ЖЖ в XML.
Это сделает чужая утилита — ljdump
Придется установить Питон, открыть IDLE (Python GUI), загрузить туда утилиту и запустить. Всё спросит она сама.

После её пробега у вас будет директория с файлами LXXX — посты и CXXX — комменты.

А на эти XMLи мы и запустим мой скрипт.
В этом виде он использует pure Java, embedded базу данных Hypersonic (HSQLDB), но можно подключиться к любой, конечно же. Только убедитесь, что JDBC driver у вас в classpath.

Парсинг и работа с БД такого типа годятся только для скриптов и небольших программ. В энтерпрайзе никто не будет загружать весь XML в память (а будут использовать SAX), и никто не будет напрямую слать SQL (а будет Connection Pool, prepared statement, batch, Hibernate какой нибудь).

Захотелось попробовать развить здесь одну любопытную дискуссию, которая была начала тема в комментах к будущему подкасту Радио-Т (кстати сами подкасты бывают иногда интересны), но тут же заглохла из-за отсутствия кворума.

Дискуссия о, собственно, будущем Java как языка, и как платформы.
Если вкратце — что могут сделать те, кто направляет развитие Java, чтобы удержать ее на плаву в течении долгого времени. По ссылке выше обсуждение пошло было в сторону того, почему в лабораториях Microsoft Research более или менее активно разрабатываются альтернативные языки для платформы .NET (такие, например, как F#), а вот Sun/Oracle с такой поддержкой альтернативным языкам отстают.