Комментарии 53
Какая-то помесь питона с жикварей…
Слышал, что разрабатывают на груви, но не видел ни груви программистов, ни продуктов на груви.
Расскажите хоть саксес стори какой…
Слышал, что разрабатывают на груви, но не видел ни груви программистов, ни продуктов на груви.
Расскажите хоть саксес стори какой…
В основном success stories связаны с фреймворком на groovy — на grails.
А вообще вот — video.google.com/videoplay?docid=-7629776691121323726#
А вообще вот — video.google.com/videoplay?docid=-7629776691121323726#
есть модуль goovy под ibm websphere portal, в принципе, оно работает, но…
штука глючная, изменения в скриптах отслеживает с трудом, бывает что скомпилированый скрипт «залипает», и надо производить танцы с бубнами типа физического перезапуска кластера и смены даты файлов скриптов, чтобы оно их перекомпилило
вроде в новой версии обещают что починили, но ставить эксперименты на боевой системе не хочется
штука эта от сторонней компании, фриварная и без обязательств, соответственно ibm ее не суппортит, и если что вдруг легло, то типа разбирайтесь сами
в общем, пока в корпоративный сегмент им рано, вот лет через 5, как повзрослеют…
штука глючная, изменения в скриптах отслеживает с трудом, бывает что скомпилированый скрипт «залипает», и надо производить танцы с бубнами типа физического перезапуска кластера и смены даты файлов скриптов, чтобы оно их перекомпилило
вроде в новой версии обещают что починили, но ставить эксперименты на боевой системе не хочется
штука эта от сторонней компании, фриварная и без обязательств, соответственно ibm ее не суппортит, и если что вдруг легло, то типа разбирайтесь сами
в общем, пока в корпоративный сегмент им рано, вот лет через 5, как повзрослеют…
Я писал в блоге об этом некоторое время назад — дам поэтому ссылку mantonov.blogspot.com/2011/04/groovy-c-java-production-1.html
Мы внедряем Groovy достаточно давно в разных частях достаточно крупного (в общей сложности более 3 млн строк Java кода) и достаточно старого проекта на Java, наталкиваемся на некоторые неожиданные сложности и нестыковки, но пока вроде бы получается находить решения.
Мы внедряем 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).
Из популярных продуктов — 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).
Возможно, это оттого, что некоторые приведенные примеры действитульно не очень удачны, а некоторых интересных примеров нет, а те что есть — немного искусственны.
В 2024, ковыряя jenkins, узнал про groovy ))
Можно создать классы на Groovy с аннотациями из hibernate, а затем использовать эти домены в java коде? Нет каких-то подводных камней?
Для Groovy видел кучу всяких библиотек и фреймворков — есть там что-нибудь интересного, чтобы взяться за голову и сказать — как же я раньше без этого жил? :)
Для Groovy видел кучу всяких библиотек и фреймворков — есть там что-нибудь интересного, чтобы взяться за голову и сказать — как же я раньше без этого жил? :)
Насчет hibernate не пробовал, но в EJB проектах можно использовать groovy и аннотации — ссылка. Думаю, все будет хорошо работать. Так же при смешивании java и groovy классов лучше придерживаться такого правила: интерфесы писать на java, а реализацию — на groovy. Тогда эти интерфейсы затем можно использовать где угодно, хоть в java, хоть в groovy.
Насчет взяться за голову — да, есть такое. После python в джаве иногда становится очень грустно… И на помощь приходит groovy.
И код выразителен. Вот, например, сравните:
Groovy:
Java:
Какой вариант вам больше нравится? :)
Насчет взяться за голову — да, есть такое. После 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:
пусто :)
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).
Tapestry 5 рекомендую, если делаете что-то кастомное и оригинальное. Если же нужно сделать, что-то шаблонное, типа блога за 15 минут, то со сторонними компонентами в Tapestry 5 сейчас не очень (значительно хуже, чем с плагинами в Grails).
Я делал так — совершенно спокойно все работает. Единственный подводный камень, с которым я столкнулся: по некоторым причинам я использовал propertyMissing() — перехватчик обращения к несуществующему полю класса для других целей. И когда Hibernate из-за ошибки в маппинге попытался присвоить значение несуществующему полю в классе, результат был совершенно неожиданный, и я довольно долго искал причину.
Для меня очень полезной была поддержка XML-а в Груви. Намного удобнее, чем в Джаве. Но когда я стал разбираться со Скалой, понял, что это все были детские игрушки :)
Очень хорошо написаный обзор языка. Приятно почитать и позволяет хоть слегка, но понимать что написано в коде.
Я обожаю груви. Пишу на нём под фреймвёрк grails. Я даже не знаю, сколько я потратил на его изучение — наверно совсем мало. Просто прочитал getting started и пару статей. Язык невероятно интуитивный и лаконичный.
Очень много примеров и решений на груви можно найти в разделе groovy goodness вот здесь — mrhaki.blogspot.com/
Очень много примеров и решений на груви можно найти в разделе groovy goodness вот здесь — mrhaki.blogspot.com/
Хороший обзор, но стоит уточнить, что closures это на самом деле совсем не функции в Groovy, хоть и выглядят как функциии. Это объекты (экземляры Closure), что принципиально отличает их от функций-методов.
Да, в этом плане кстати я рекомендую иногда компилировать простенькие классы на Groovy в байткод, а потом декомпилировать в Java :) Тогда можно видеть, как это все внутри склеивается. Интересно и познавательно.
А чем вы декомпилируете груви?
У меня через jd-gui нечитабельная фигня получается.
У меня через jd-gui нечитабельная фигня получается.
DJ Java Decompiler, jd-gui, cavaj… В принципе там все идет от движка JAD :) с допиливаниями.
А мусор — мусор будет всегда, естественно, т.к. кодогенератор груви генерит много кода для поддержки метапрограммирования (в частности, роутинг вызовов методов через метаклассы и прочее).
Но при желании из него можно вытащить интересные вещи. Кому нибудь будет интересен пост о декомпилировании груви? ;)
А мусор — мусор будет всегда, естественно, т.к. кодогенератор груви генерит много кода для поддержки метапрограммирования (в частности, роутинг вызовов методов через метаклассы и прочее).
Но при желании из него можно вытащить интересные вещи. Кому нибудь будет интересен пост о декомпилировании груви? ;)
Мне точно будет )))
https://habr.com/ru/post/135797/ примерно в тему, и больше не стали писать ничего?. Жаль..
Еще нашел интересную ссылку — groovyconsole.appspot.com/
Веб-интерпретатор groovy
Веб-интерпретатор groovy
По моему скромному личному мнению scala выглядит как-то попристойнее, мы ее мирили с vaadin фрейворком, все работало, объем кода сокращается в разы.
Ну, строго говоря, Groovy тоже никогда не интерпретируется, а всегда предварительно компилирует весь класс (-ы) в байткод. Другое дело, что он может промежуточно создавать .class файлы на диске, подобно javac (используя компилятор groovyc), или загружать код из файлов .groovy, генерить байткод и запускать его на выполнение (через Groovy Script Engine).
В Groovy есть одно приемущество (хотя, конечно, это можно оспорить) — java код без изменений в 99% случаях будет работать в Groovy. И поэтому учиться groovy для java программиста намного проще. Можно сначала писать как в джаеве, и, постепенно пробуя на вкус все удобства groovy, использовать его больше и больше.
В скала же синтаксис в большей степени не похож на джаву, поэтому нужно потратить некоторое время на освоение — сразу сесть и начать писать код, постепенно изучая язык лучше, не получится.
Но, думаю, эти два языка заняли свои ниши и поселились на jvm всерьез и надолго.
В скала же синтаксис в большей степени не похож на джаву, поэтому нужно потратить некоторое время на освоение — сразу сесть и начать писать код, постепенно изучая язык лучше, не получится.
Но, думаю, эти два языка заняли свои ниши и поселились на jvm всерьез и надолго.
Мне так нравиться название Elvis operator если наклонить голову влево то это точно он ?:
Groovy — относительно неплохой язык скриптования для тех кто привык к Java. Это по сути немного syntax suggar которые так не хватает яве.
Но дается с очень большой ценой — производительность груви в среднем раз в 10 меньше чем явы и не важно байт код это или режим скрипта — все дело в мета программирование и количестве оберток которые нужно дернуть прежде чем добраться до реального метода.
Если говорить о Grails то его проблема в количестве зависимостей от сторонних библиотек, так что если понадобится добавить свою зависимость есть большая вероятность что она будет несовместима.
В общем лично я предпочитаю python и scala. Хотя возможно все началось c groovy.
Но дается с очень большой ценой — производительность груви в среднем раз в 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?
Groovy появился вроде как в 2003г. и разработчик просто не знал о scala, иначе groovy просто не появился бы)
James Strachan — Scala as the long term replacement for java/javac?
Спасибо, не знал что scala так стар. В википедии правда сказано что оба языка появились в 2003.
Думаю груви бы появился в любом случае, groovy это логичная надстройка над java, а scala совершенно новый язык в котором иногда даже сложно использовать код на java(разница в collection api)
Думаю груви бы появился в любом случае, 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 списывать рано. Для него написано огромное количество библиотек, и использование его для написания скриптов или второстепенных утилит очень оправдано. Однако для основного проекта я бы использовал его с осторожностью.
«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 и иже с ним).
C другой стороны, без такой системы типов / поддержки метаклассов вы бы наверное не смогли добавлять или изменять метода / поля в отдельных объектах динамически (через ExpandoMetaClass и иже с ним).
Кстати, в идее прекрасно работает автокомплит в большей части случаев (моих?).
>Но дается с очень большой ценой — производительность груви в среднем раз в 10 меньше чем явы и не важно байт код это или режим скрипта — все дело в мета программирование и количестве оберток которые нужно дернуть прежде чем добраться до реального метода.
а вы groovy++ пробовали?
а вы groovy++ пробовали?
нет, но кажется мне что тогда природу многие прелести груви например DSL.
Grails хорошо, когда есть задумка на «стартапчик» и пока не пропал угар быстренько слабать. А что делать потом (переписывать на что-то другое) — уже смотреть по необходимости.
Автор, спасибо большое. Все кратко, ясно и лаконично!
похоже на фреймворк web2py / web4py на Python
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Groovy за 15 минут – краткий обзор