Pull to refresh

Comments 52

Какая-то помесь питона с жикварей…
Слышал, что разрабатывают на груви, но не видел ни груви программистов, ни продуктов на груви.
Расскажите хоть саксес стори какой…
есть модуль goovy под ibm websphere portal, в принципе, оно работает, но…

штука глючная, изменения в скриптах отслеживает с трудом, бывает что скомпилированый скрипт «залипает», и надо производить танцы с бубнами типа физического перезапуска кластера и смены даты файлов скриптов, чтобы оно их перекомпилило
вроде в новой версии обещают что починили, но ставить эксперименты на боевой системе не хочется

штука эта от сторонней компании, фриварная и без обязательств, соответственно ibm ее не суппортит, и если что вдруг легло, то типа разбирайтесь сами

в общем, пока в корпоративный сегмент им рано, вот лет через 5, как повзрослеют…
Я писал в блоге об этом некоторое время назад — дам поэтому ссылку mantonov.blogspot.com/2011/04/groovy-c-java-production-1.html

Мы внедряем Groovy достаточно давно в разных частях достаточно крупного (в общей сложности более 3 млн строк Java кода) и достаточно старого проекта на Java, наталкиваемся на некоторые неожиданные сложности и нестыковки, но пока вроде бы получается находить решения.

В целом, я вашу скептичность полностью поддерживаю по поводу внедрения в продакшен. Но оно заслуживает того, чтобы поэкспериментировать.
у нас оно уже в проме, и в целом живет
при обновлениях регулярно косяки вылазят, но вроде научились с ними бороться
потому и новую версию движка пока не хочется ставить
Groovy разрабатывается компанией SpringSource(подразделение VMWare) — команда, что разрабатывает Spring, Apache Tomcat, Apache HTTPD, RabbitMQ, Redis, AspectJ и многие другие опенсорсные(и не только) проекты. Groovy-related вещами занимается около 8 человек. Success stories можно почитать на сайте SS.

Из популярных продуктов — Grails, на Dice.com вакансий по нему больше чем по Tapestry, Wicket, примерно одинаковое с Django & Zend. Очень активный мейл-лист.

Groovy также популярен как DSL: Gradle & Maven 3 (Build Tools), Geb (Web testing via Selenium Webdriver), Griffon (Java GUI), Spock (BDD/TDD), GPars (Parallelism, Concurrency, Actors..), Play! framework(as a Template Engine). Есть плагины для анализа кода — CodeNarc, опциональное статическое типизирование Groovy++.

Есть поддержка IDE: SpringSource Tool Suite(бесплатный набор плагинов к Eclipse) & IntelliJ IDEA(Groovy есть даже в бесплатной Community версии), Netbeans + текстовые редакторы.

Вообщем вполне себе здоровое сообщество — не забываем, что вы можете использовать без проблем Java библиотеки, наследывать Java классы и наоборот (JavaClass extends GroovyClass).
Возможно, это оттого, что некоторые приведенные примеры действитульно не очень удачны, а некоторых интересных примеров нет, а те что есть — немного искусственны.
Можно создать классы на Groovy с аннотациями из hibernate, а затем использовать эти домены в java коде? Нет каких-то подводных камней?

Для Groovy видел кучу всяких библиотек и фреймворков — есть там что-нибудь интересного, чтобы взяться за голову и сказать — как же я раньше без этого жил? :)
Насчет hibernate не пробовал, но в EJB проектах можно использовать groovy и аннотации — ссылка. Думаю, все будет хорошо работать. Так же при смешивании java и groovy классов лучше придерживаться такого правила: интерфесы писать на java, а реализацию — на groovy. Тогда эти интерфейсы затем можно использовать где угодно, хоть в java, хоть в groovy.

Насчет взяться за голову — да, есть такое. После python в джаве иногда становится очень грустно… И на помощь приходит groovy.

И код выразителен. Вот, например, сравните:
Groovy:
def query = group.getInstanceOf("/index");
query.setAttributes(["column": "subject", "table": "emails"])


Java:
ST query = group.getInstanceOf("/index");
Map<String, String> atrs = new HashMap<String, String>();
atrs.put("column", "subject");
atrs.put("table", "emails");
query.setAttributes(atrs);


Какой вариант вам больше нравится? :)
В java можно и так:

query.setAttributes(new HashMap({{
put(«column», «subject»);
put(«table», «emails»);
}}));

Но синт. сахар меня не возбуждает уже, вышел из этого возраста :) Для меня важнее наличие клёвых библиотек и фреймворков, которые упрощают и ускоряют разработку. Например, в Tapestry 5 и не нужно так делать с параметрами для шаблона. Т.е. не нужно вот этого кода вообще:

groovy+какой-то веб-фреймворк:
def query = group.getInstanceOf("/index");
query.setAttributes([«column»: «subject», «table»: «emails»])

java+tapestry5:
пусто :)
Так можно и tapestry использовать в groovy.
Кстати, не пробовал этот фреймворк, рекомендуете?
Ну да, я поэтоу и думаю не уходить в крайности, а использовать плюсы groovy в java.

Tapestry 5 рекомендую, если делаете что-то кастомное и оригинальное. Если же нужно сделать, что-то шаблонное, типа блога за 15 минут, то со сторонними компонентами в Tapestry 5 сейчас не очень (значительно хуже, чем с плагинами в Grails).
Я делал так — совершенно спокойно все работает. Единственный подводный камень, с которым я столкнулся: по некоторым причинам я использовал propertyMissing() — перехватчик обращения к несуществующему полю класса для других целей. И когда Hibernate из-за ошибки в маппинге попытался присвоить значение несуществующему полю в классе, результат был совершенно неожиданный, и я довольно долго искал причину.
Для меня очень полезной была поддержка XML-а в Груви. Намного удобнее, чем в Джаве. Но когда я стал разбираться со Скалой, понял, что это все были детские игрушки :)
Очень хорошо написаный обзор языка. Приятно почитать и позволяет хоть слегка, но понимать что написано в коде.
Я обожаю груви. Пишу на нём под фреймвёрк grails. Я даже не знаю, сколько я потратил на его изучение — наверно совсем мало. Просто прочитал getting started и пару статей. Язык невероятно интуитивный и лаконичный.
Очень много примеров и решений на груви можно найти в разделе groovy goodness вот здесь — mrhaki.blogspot.com/
Хороший обзор, но стоит уточнить, что closures это на самом деле совсем не функции в Groovy, хоть и выглядят как функциии. Это объекты (экземляры Closure), что принципиально отличает их от функций-методов.
Да, в этом плане кстати я рекомендую иногда компилировать простенькие классы на Groovy в байткод, а потом декомпилировать в Java :) Тогда можно видеть, как это все внутри склеивается. Интересно и познавательно.
А чем вы декомпилируете груви?
У меня через jd-gui нечитабельная фигня получается.
DJ Java Decompiler, jd-gui, cavaj… В принципе там все идет от движка JAD :) с допиливаниями.

А мусор — мусор будет всегда, естественно, т.к. кодогенератор груви генерит много кода для поддержки метапрограммирования (в частности, роутинг вызовов методов через метаклассы и прочее).

Но при желании из него можно вытащить интересные вещи. Кому нибудь будет интересен пост о декомпилировании груви? ;)
По моему скромному личному мнению scala выглядит как-то попристойнее, мы ее мирили с vaadin фрейворком, все работало, объем кода сокращается в разы.
Тоже смотрю на скалку. Ее можно использовать как скриптовый язык? Хотелось бы разрабатывать не компилируя, а интерпретируя, а сборку уже компилять.
Ну, строго говоря, Groovy тоже никогда не интерпретируется, а всегда предварительно компилирует весь класс (-ы) в байткод. Другое дело, что он может промежуточно создавать .class файлы на диске, подобно javac (используя компилятор groovyc), или загружать код из файлов .groovy, генерить байткод и запускать его на выполнение (через Groovy Script Engine).

Кстати, рекомендую книжку Groovy in Action. 2nd edition. В написании принимали участие авторы и коммитеры языка и рантайма.
Что-то второго издания в сети найти не могу. Покупали книжку эту?
В Groovy есть одно приемущество (хотя, конечно, это можно оспорить) — java код без изменений в 99% случаях будет работать в Groovy. И поэтому учиться groovy для java программиста намного проще. Можно сначала писать как в джаеве, и, постепенно пробуя на вкус все удобства groovy, использовать его больше и больше.
В скала же синтаксис в большей степени не похож на джаву, поэтому нужно потратить некоторое время на освоение — сразу сесть и начать писать код, постепенно изучая язык лучше, не получится.

Но, думаю, эти два языка заняли свои ниши и поселились на jvm всерьез и надолго.
Мне так нравиться название Elvis operator если наклонить голову влево то это точно он ?:
Groovy — относительно неплохой язык скриптования для тех кто привык к Java. Это по сути немного syntax suggar которые так не хватает яве.

Но дается с очень большой ценой — производительность груви в среднем раз в 10 меньше чем явы и не важно байт код это или режим скрипта — все дело в мета программирование и количестве оберток которые нужно дернуть прежде чем добраться до реального метода.

Если говорить о Grails то его проблема в количестве зависимостей от сторонних библиотек, так что если понадобится добавить свою зависимость есть большая вероятность что она будет несовместима.

В общем лично я предпочитаю python и scala. Хотя возможно все началось c groovy.
Ну строго говоря, опять же, Groovy не имеет режима скрипта, если вы подразумеваете под этим чистую интерпретацию. Он всегда выполняет байткод.

Насчет производительности — судить не берусь, но мне ее в целом хватает.
Исследовательские работы по Scala начались еще в 2001 году и были инициированы разработчиком Generic'ов в Java — Мартином Одерски.

Groovy появился вроде как в 2003г. и разработчик просто не знал о scala, иначе groovy просто не появился бы)

James Strachan — Scala as the long term replacement for java/javac?
Спасибо, не знал что scala так стар. В википедии правда сказано что оба языка появились в 2003.
Думаю груви бы появился в любом случае, groovy это логичная надстройка над java, а scala совершенно новый язык в котором иногда даже сложно использовать код на java(разница в collection api)
Слова James Strachan, создателя Groovy:

«I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.»

Основной недостаток Groovy — это динамическая типизация, когда тип переменной может быть вычислен только в runtime. В Scala была реализована сложная модель вычисления статических типов на этапе компиляции.

Один из бонусов type-safe языка, который я люблю — это то, что IDE знает типы и предлагает список полей и методов по Ctrl-Space В Groovy же приходится ползать в документацию.

Тем не менее для Groovy списывать рано. Для него написано огромное количество библиотек, и использование его для написания скриптов или второстепенных утилит очень оправдано. Однако для основного проекта я бы использовал его с осторожностью.
В нем не динамическая типизация. Тип переменной вычисляется при компиляции в байткод, насколько я понимаю. По край ней мере так это выглядит при декомпиляции.
В нем опциональная / утиная типизация, скажем так. Когда вы пишете def x = «mystring», x.class будет Object. Вывода типов нет.

C другой стороны, без такой системы типов / поддержки метаклассов вы бы наверное не смогли добавлять или изменять метода / поля в отдельных объектах динамически (через ExpandoMetaClass и иже с ним).
По крайней мере groovy console с вами не согласен:
groovy> def x = "mystring"
groovy> x.class

Result: class java.lang.String
Потому что класс обределяется в рантайме. Если посмотреть код через jad, то там будет что-то типа Object x = (Object)«mystring». Если в джаве написать такое, то x.getClass() тоже вернет String.
Кстати, в идее прекрасно работает автокомплит в большей части случаев (моих?).
>Но дается с очень большой ценой — производительность груви в среднем раз в 10 меньше чем явы и не важно байт код это или режим скрипта — все дело в мета программирование и количестве оберток которые нужно дернуть прежде чем добраться до реального метода.

а вы groovy++ пробовали?
нет, но кажется мне что тогда природу многие прелести груви например DSL.
ну тогда это звучит так: мы предлагаем вам новую функциональность, одна из фич которой ее можно отключить. И тогда спрашивается зачем было включать.

Groovy это groovy, и если его и имеет смысл использовать то только в полном объеме.
нет, не так.
если код можно вывести-типизировать и этим его ускорить — для него включится статическая типизация, если нет — останется динамическая. и эта вся магия включается одной аннотацией.
Grails хорошо, когда есть задумка на «стартапчик» и пока не пропал угар быстренько слабать. А что делать потом (переписывать на что-то другое) — уже смотреть по необходимости.
Автор, спасибо большое. Все кратко, ясно и лаконично!
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.

Articles