Groovy вместе (и вместо) с Java в продакшене.
Собствнно, сабж. Этот пост - некоторое мое размышление о проекте, может кому-то будет просто интересно. А может, у кого-то есть здесь опыт именно в таких вещах, и он прокомментирует. А может, у кого-то просто очень богатый жизненный и профессиональный опыт, и он даст мудрый совет на все времена (ТМ). Итак.
В последнее время стараюсь сойти с прямых и строгих рельс стальных рельс Java на языки под платформу JVM. Приложение - платформа для построение систем управления цепочками поставок (перевозная логистика, складская логистика, розничная торговля), включает в себя разные компоненты для интеграции, расчетов прогнозов (статистические и эвристические методы) , планирование заказов, трекинг перевозок и еще много чего. Написана почти вся на Java (с примесью, как водится, SQL, HTML/CSS/Javascript, + в отдельных компонентах встречается флеш и питон). Пока что мы выбрали Groovy. Почему?
Какие были требования к новому дополнительному языку?
1) Тесты. Написание тестов, особенно таких, которые работают в сервлет-контейнере и базой данных, занимает много времени. По разным причинам.
Первая, это то что сам язык Java весьма громоздкий, и даже отличная поддержка IDE мало помогает. Когда появляется множество тест-классов каждый по 500-1000 строк кода, это начинает утомлять.
Вторая специфическая - написание контейнерных тестов на Java и их дописывание / отладка часто требует рестартов appserver-a, который занимает 3-4 минуты. Собственно, любое изменение кода, кроме изменения "кода внутри методов" требует рестарта JBoss-a.
2) Вокрфлоу и прочая бизнес логика, где скорость выполнения Java-кода (байткода) не является узким местом, а вот писать на Java сложную итерацию по коллекциям, проверку сложных условий, и прочую бизнес логику бывает несколько утомительно.
3) Поддержка метапрограммирования - в понятном, не слишком зубодробительном виде, но достаточная, чтобы создавать DSL-языки для таких вещей, как моделирование данных в БД, построение экранов с отчетами, конфигурации портлетов - в общем того, что в мире Java-энтерпрайза традиционно программируется в XML-e.
Пока это все с причинами.
Какой же есть выбор?
1) Очевидно, хотелось бы что-то компилирующееся в Java-байткод. Лучше, чтобы была полная двусторонняя интеграция с Java на уровне байткода JVM.
2) Предлагаюших писать на Lisp или Haskell не нашлось:). Да - на Nemerle тоже ;)
3) Можно брать языки, портированные под JVM - JRuby, Jython. Jython мы используем кое-где, но только для скриптинга и работы с файлами в основном. Имело бы смысл, если бы кто-то из нас хорошо знал Ruby или Python. Таковые есть, но оччень мало.
4) Наконец, можно писать на языках, специально написанных под JVM, с синтаксисом, более похожим на Java, с явным упором на отличную интеграцию с ней, но перенявших фишки языков из предыдущих пунктов. Таких нашлось два - Groovy и Scala.
Scala пока что отпала (к некоторому моему сожалению) по ряду причин - сложновата концептуально, заметный упор в функциональное программирование, выше порог вхождения, круче кривая изучения, меньше (вероятно) ореол использования. Плюсов у нее тоже немало, но в итоге они не перевесили.
Как итог, пока что медленно и осторожно пробуем интегрировать код на Groovy в намеченных областях.
Да - мои мысли в этом посте немного связаны с этими.
В последнее время стараюсь сойти с прямых и строгих рельс стальных рельс Java на языки под платформу JVM. Приложение - платформа для построение систем управления цепочками поставок (перевозная логистика, складская логистика, розничная торговля), включает в себя разные компоненты для интеграции, расчетов прогнозов (статистические и эвристические методы) , планирование заказов, трекинг перевозок и еще много чего. Написана почти вся на Java (с примесью, как водится, SQL, HTML/CSS/Javascript, + в отдельных компонентах встречается флеш и питон). Пока что мы выбрали Groovy. Почему?
Какие были требования к новому дополнительному языку?
1) Тесты. Написание тестов, особенно таких, которые работают в сервлет-контейнере и базой данных, занимает много времени. По разным причинам.
Первая, это то что сам язык Java весьма громоздкий, и даже отличная поддержка IDE мало помогает. Когда появляется множество тест-классов каждый по 500-1000 строк кода, это начинает утомлять.
Вторая специфическая - написание контейнерных тестов на Java и их дописывание / отладка часто требует рестартов appserver-a, который занимает 3-4 минуты. Собственно, любое изменение кода, кроме изменения "кода внутри методов" требует рестарта JBoss-a.
2) Вокрфлоу и прочая бизнес логика, где скорость выполнения Java-кода (байткода) не является узким местом, а вот писать на Java сложную итерацию по коллекциям, проверку сложных условий, и прочую бизнес логику бывает несколько утомительно.
3) Поддержка метапрограммирования - в понятном, не слишком зубодробительном виде, но достаточная, чтобы создавать DSL-языки для таких вещей, как моделирование данных в БД, построение экранов с отчетами, конфигурации портлетов - в общем того, что в мире Java-энтерпрайза традиционно программируется в XML-e.
Пока это все с причинами.
Какой же есть выбор?
1) Очевидно, хотелось бы что-то компилирующееся в Java-байткод. Лучше, чтобы была полная двусторонняя интеграция с Java на уровне байткода JVM.
2) Предлагаюших писать на Lisp или Haskell не нашлось:). Да - на Nemerle тоже ;)
3) Можно брать языки, портированные под JVM - JRuby, Jython. Jython мы используем кое-где, но только для скриптинга и работы с файлами в основном. Имело бы смысл, если бы кто-то из нас хорошо знал Ruby или Python. Таковые есть, но оччень мало.
4) Наконец, можно писать на языках, специально написанных под JVM, с синтаксисом, более похожим на Java, с явным упором на отличную интеграцию с ней, но перенявших фишки языков из предыдущих пунктов. Таких нашлось два - Groovy и Scala.
Scala пока что отпала (к некоторому моему сожалению) по ряду причин - сложновата концептуально, заметный упор в функциональное программирование, выше порог вхождения, круче кривая изучения, меньше (вероятно) ореол использования. Плюсов у нее тоже немало, но в итоге они не перевесили.
Как итог, пока что медленно и осторожно пробуем интегрировать код на Groovy в намеченных областях.
Да - мои мысли в этом посте немного связаны с этими.