Groovy inspiration — Feel the difference

image

Почему Groovy


Будучи Java разработчиком, некоторое время назад я начал посматривать в сторону других языков программирования, и, думаю об этом размышлял далеко не только я. Некоторые мои знакомые, в свое время имеющие отнюдь не малый опыт в разработке под Java — платформу, решительно начали двигаться по рельсам (Rails), соответственно используя Ruby, кто-то еще подумывает приручить Питона с приложением к нему в виде Django. Появляется достаточно книг о том, как Java — программисту мигрировать в мир динамических языков. Может ли что-то нас остановить?

Так сложилось, что не так давно мне довелось наблюдать разработку на Ruby&Rails с соседнего от напарника стула и даже самому кое-что пописать, временами выслушивая критику в сторону Java — style. В результате, пока точно не знаю, к сожалению или счастью, но меня не затянуло. Все-таки не хотелось оставлять, возможно, по определенным меркам не очень большой, но все же для меня основной — почти 3х летний опыт работы с Java. В то же время я могу легко наплевать на немалую часть времени, потраченного на изучение AS3/Flex, чьи компоненты были неотъемлемыми при написании приложений, использующих технологии потокового видео. Но, к счастью, с этой практикой вроде покончено.
В эти выходные мне на глаза попалась какая-то статья про Groovy, точно не могу вспомнить с чего все началось. После этого, посмотрев пару записанных конференций, в этот раз Groovy меня определенно заинтересовал. Язык разработан для платформы Java и является наиболее популярным из других, динамических языков, работающих в JVM. Порадовала, конечно, довольно простая интеграция с компонентами на привычном мне языке, возможность использования хорошо знакомых фреймворков, работа в OSGi среде — все то, что реально останавливает меня от ухода из мира Java, давая при этом возможность писать элегантный код.
Ну, хватит воды, а то ее получилось уже довольно много, лучше приступлю к делу и попытаюсь объяснить почему меня вдохновил Groovy, экскурсия по которому вошла в число основных моих занятий на прошедшие выходные.

JavaBeans и Groovy


Изучив немного Java и познав основы инкапсуляции, неважно в каком порядке эти два действия совершены, большинство из нас сталкивается с необходимостью написания JavaBeans — содания полей класса и генерации всеми “любимых” getters/setters. В IDE для этого, кажется, даже HotKey сделали. Ниже представлен JavaBean на Java и Groovy соответственно.
//Java
import java.util.Date;

public class Employee {
 private String firstName;
 private String lastName;
 private Date dateSince;

 public String getFirstName() {
  return firstName;
 }

 public void setFirstName(String firstName) {
  this.firstName = firstName;
 }

 public String getLastName() {
  return lastName;
 }

 public void setLastName(String lastName) {
  this.lastName = lastName;
 }

 public Date getDateSince() {
  return dateSince;
 }

 public void setDateSince(Date dateSince) {
  this.dateSince = dateSince;
 }
}

//Groovy
class Employee {
 String firstName
 String lastName
 Date dateSince
}

Получилось 31 строка на Java против 5ти на Groovy.
И это еще без дополнительных конструкторов с параметрами, написание в Groovy которых вообще не требуется:
def e = new Employee(firstName:'Ivan', lastName:'Petrov')

Скажете где private или то, что не всегда надо давать возможность менять состояние объектов (-seeters + constructor)? И такая проблема оказывается решаемой с аннотацией @Immutable
import groovy.lang.Immutable;

@Immutable class Employee {
 String firstName
 String lastName
 Date dateSince
}

Exceptions


Касательно этой темы можно спорить достаточно долго… Как известно в Java исключения делятся на checked (проверяемые) и unchecked (непроверяемые). В Groovy же все исключения можно отнести к классу unchecked, то есть вас никто не заставит отлавливать их при вызове методов или указывать, что обработка будет где-то выше. Тут можно подумать о том, что все-таки мы не дети и надзиратель для этого нам не нужен. Но, в то же время, никто не мешает указывать throws или оборачивать код в try/catch блоки.

Делегирование


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

import java.text.SimpleDateFormat

class Event {
 @Delegate Date when
 String title, url
}

def df = new SimpleDateFormat("yyyy/MM/dd")

def gr8conf = new Event(title: "GR8 Conference",
url: "http://www.gr8conf.org",
when: df.parse("2009/05/18"))
def javaOne = new Event(title: "JavaOne",
url: "http://java.sun.com/javaone/",
when: df.parse("2009/06/02"))

assert gr8conf.before(javaOne.when)


Как видно, теперь можно без проблем использовать методы класса Date. Выражение gr8conf.before(javaOne.when) кажется вполне логичным, сохраняя при этом чистоту кода.
Пример, конечно, очень примитивный, но, думаю каждый сможет у себя в голове воспроизвести те моменты, в которых бы это ему могло помочь.

Замыкания (Closures)


В Java замыканий нет, и точно нельзя сказать когда они появятся, в Java 8 как планируется или еще раз перенесутся. В Groovy же их можно использовать уже сейчас. Я не буду тут очень детально рассматривать замыкания, думаю, это тема для отдельной статьи, а просто приведу один из примеров того, как можно сократить код.

Пусть у нас есть список рабочих (Employee), нужно выбрать из них подмножество, удовлетворяющее определенному критерию выбора: это может быть зарплата, возраст или отдел.

List getStaffWithMuchSalaryThan(List staff, double salary);
List getStaffYoungerThan(List staff, int age);
List getStaffByDepartment(List staff, Dept dept);


В каждом примерно одинаковая логика: пробегаем по циклу, проверяя удовлетворение условиям. Если удовлетворяет — добавляем в результирующий список.
То есть на Java имеем три метода вида:

public List getStaffWithMuchSalaryThan(List staff, double salary) {
 List result = new ArrayList();
 for(Employee e: staff) {
  if(e.getSalary() >= salary) {
   result.add(e);
  }
 }
 return result;
}

и так для каждого из указанных выше еще двух методов. Конечно, проблема дизайна кода может решиться с помощью паттерна Strategy, но количество строк останется довольно большим.

Теперь попробуем написать то же самое, используя замыкания.

//список рабочих
def staff = [
 new Employee(firstName: 'A', salary:500, age:20, dept:'K'),
 new Employee(firstName: 'B', salary:700, age:30, dept:'K'),
 new Employee(firstName: 'C', salary:1000, age:25, dept:'A2') ]

// определение замыкания
def getStaffWithCriteria(staff, criteria) {
 result = []
 for(e in staff) {
 if(criteria(e)) result.add(e)
 }
 result
}

println getStaffWithCriteria(staff, {e -> e.salary > 600}) //зарплата выше 600
println getStaffWithCriteria(staff, {e -> e.age < 27}) //все, кто моложе 27 лет
println getStaffWithCriteria(staff, {e -> e.dept == 'K'}) //работающие в отделе K


// UPD: И еще без одного велосипеда код упрощается до:

println staff.grep {e -> e.salary > 600}
println staff.grep {e -> e.age < 27}
println staff.grep {e -> e.dept == 'K'}

Спасибо thevery

Результат:
[B, C]
[A, C]
[A, B]


Работа с коллекциями


Groovy сильно упрощает работу со списками, начиная от их создания до итерации по ним.

Вполне логичное:
def list = ['a', 'b', 'c']

вместо кода на Java:

List list = new ArrayList();
list.add(«a»);
list.add(«b»);
list.add(«c»);

Предположим нам надо просто вывести список элементов:
в Java:
for(String s: list) {
 System.out.println(s);
}

в Groovy:
list.each {println it}

Цикл на Java будет не таким уже привлекательным, если нам необходим доступ к индексу элемента. Тогда не обойтись без цикла вида, представленного ниже, или введя дополнительную переменную, вместе с этим выполняя операцию инкремента над ней внутри цикла:
for (int i = 0; i < list.size(); i++) {
 System.out.println(i + " - " + list.get(i));
}


В Groovy и эта задача имеет более простое решение

list.eachWithIndex {e, i -> println “${i} - ${e}”}

Также когда-то всем приходилось писать код для вывода списка с разделителями, с условием, что после последнего элемента разделителя быть не должно. И вот, это одно, режущее глаза условие на проверку, является ли элемент последним в цикле.

Код на groovy для этой цели сильно упрощается с использованием метода join

list.join(', ')

произведет строку: “a, b, c”

Сборка проекта


Тем, кто привык использовать инструменты для сборки проектов типа Ant, Maven, взамен встроенному функционалу сред разработки, можно посоветовать попробовать Gradle. Несмотря на мою немалую любовь к Maven для сборки Java проектов, Gradle для меня выглядит гораздо приятнее. К сожалению, в рамки этой статьи, все, что можно сказать хорошего о Gradle не уместится. Кстати, вчера, 19 декабря, состоялся релиз версии 0.9, включающий множество изменений.

Заключение


Безусловно, эта статья не претендует на титул изречений гуру или основное руководство, побуждающее использовать Groovy. Больше хотелось просто поделиться новыми впечатлениями. Но будет очень неплохо, если дальнейшее изучение этого языка позволит вам остаться приверженцем платформы Java, внеся при этом много динамических возможностей от Groovy. Здесь была рассмотрена лишь малая часть того, как Groovy может помочь сделать код более простым и элегантным, но я надеюсь, что часть читателей на этом не остановятся и попробуют множество других вкусностей, предлагаемых этим языком. В завершение можно обратить внимание на то, что Groovy — язык молодой и в настоящее время развивается довольно активно своим комьюнити и отчасти благодаря инвестициям со стороны SpringSource. Де-факто веб-фреймворком для языка является Grails.
Основные источники

groovy.codehaus.org
www.infoq.com/presentations/Transforming-to-Groovy (смены картинок презентации не дождетесь, можно смело жать fullscreen на видео)
www.infoq.com/presentations/Industrial-Strength-Groovy
www.asert.com.au/pubs/Groovy/Groovy.pdf
Поделиться публикацией

Комментарии 86

    0
    Интересный язык groovy, сам игрался с ним немного.
    Подскажите, в каких крупных/средних проектах используется Grails?
      0
      Можете посмотреть на www.grails.org/Success+Stories
      Еще слышал про SAP, они строят на его основе свое решение wiki.sdn.sap.com/wiki/display/Community/Composition+On+Grails.
      Вообще, нравится, что он развивается довольно стремительно и уже не сравним со своими старые версиями. Очень жду, когда они пересядут на Gradle, тогда с адаптацией мультимодульных проектов будет значительно проще.
        +1
        Больше половины ссылок в Success Stories, которые я хотел посмотреть, не откываются.
          0
          Вам Success Stories или по ссылкам походить? Зашли, посмотрели — хватит. :)
      0
      Возможно, никто из ваших знакомвых не трогал, но ABCL, думаю, тоже стоило упомянуть.
        0
        Ну тогда и все остальные из этой таблицы en.wikipedia.org/wiki/List_of_JVM_languages#JVM_languages
          0
          Если на скобки потянуло, то лучше Clojure.
            0
            На эту тему можно долго и весело троллить, но я не в настроении, поэтому скажу просто.

            Сравните результаты запросов в гугл «web application in abcl» и «web application in clojure».
            0
            возможно, но зачем?
              0
              Зачем что? Зачем никто из знакомых sndl не трогал ABCL?
                0
                зачем нужно упоминать имхо совершенно нишевый никому неизвестный «ABCL»?
                  0
                  Django же упомянут.
                    0
                    Django/python на порядок (а то и два-три) известнее ABCL
                      0
                      Давайте статистику. Я вот только сейчас про «Django» услышал. Про Rails слышал, про ABCL-web слышал(интересовался), про «Django» — нет.

                      Сам и знакомые используют либо Rails, но чаще что-то, в данном обсуждении не появившееся. Какой-то заговор прям для ограждения меня от «Django». -_-
                        0
                        >Давайте статистику.
                        tiobe, google, google trends, indeed, dice в конце-концов — мало?
            +2
            Штука хорошая, но вот то же приложение на grails дебажить это просто обожемой. Стек трейсы валит на несколько страниц.
            +4
            По-моему вы немного замыкания путаете с функциями. В вашем примере показывается то, что в груви функции — объекты первого класса, т.е. могут быть переданы как параметры и т.д. В джаве конечно можно сымитировать функции при помощи интерфейсов, но да, это будет больше кода.
              0
              getStaffWithCriteria — несомненно метод. И все же я настаиваю на том, что конструкция, передаваемая в качастве второго параметра этому методу — ничто иное как замыкание (closure).
                +2
                В замыкании мы же должны использовать какую-либо переменную, объявленную вне этого замыкания.
                Если бы у вас было

                def averageSalary = 600
                println getStaffWithCriteria(staff, {e -> e.salary > averageSalary})

                Тогда я бы назвал это замыканием.
                  –2
                  for(e in staff) чем тут «e» не переменная вне замыкания?
                    +1
                    Дело не в том, что она «вне» а в том как код в замыкании получает к ней доступ — как параметр вызова или «заглядывая» в контекст функции которая его породила. В последнем случае такая переменная называется свободной и даёт людям, осилившим лямбда-исчисление, формальное право говорить что мы имеем дело с замыканием :)
                    0
                    — В замыкании мы же должны использовать какую-либо переменную, объявленную вне этого замыкания.
                    Сошлитесь на источник, пожалуйста. Я не понимаю такого требования.
                    Провожу аналогию с groovy.codehaus.org/JN2515-Closures: кажется все нормально
                      +1
                      Closure: closure is a first-class function with free variables that are bound in the lexical environment.
                        +3
                        На випикедии смотрю
                        Да, понятнее становится после этого вопроса. Учитывая, что эти понятия часто используется взаимозаменяемо. Для меня ваш пример — именно анонимная функция, а не замыкание.
                        0
                        Вы просто пользуетесь академической терминологией. В Groovy (а если мне не изменяет память и в Ruby) замыканиями принято называть все лямбда-выражения.
                    0
                    На сколько я знаю, Groovy произошел под вдохновлением от Ruby. Можете привести какие-нибудь преимущества Groovy над Ruby, в частности интересует скорость работы?
                      +1
                      Для себя на данный момент одним из преимуществ я вижу то, что Groovy работает в JVM (о чем было упомянуто в начале поста). По поводу производительности сложно сказать, но по моему мнению, тенденция сводится к тому, что приложения на groovy будут быстрее. Хорошей практикой является написание «критичных», в аспекте производительности частей, на Java. И, конечно, ожидаемый всеми Project Coin для JVM, который должен дать скорость динамическим языкам в jvm, сравнительную с Java.
                        0
                        спасибо за ответ!
                          0
                          М… где-то в инете натыкался на бенчмарк в котором участвовали груви и руби. jruby 1.8 был быстрее (кстати, он был быстрее ruby 1.8).
                          0
                          groovy быстрее.
                          например, вот: shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=groovy&lang2=yarv (правда он весьма старый).
                          большим плюсом в плане скорости является также наличие groovy++ — одна строчка кода(аннотация) способна сделать ваш метод/класс статически типизированным и многократно его ускорить.
                            0
                            Для скорости есть groovy++ extension.
                            +1
                            Я бы больше смотрел в сторону Scala.
                            И со мной солидарен создатель Groovy пруф: macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
                              –1
                              Это совершенно разные языки, со своими областями применения. Scala неудобна для написания скриптов, а попытка писать на Groovy большую систему равносильна самоубийству. Кстати, есть ещё довольно интересный своей статической типизацией Groovy++.
                                +2
                                А чем она неудобна для скриптов?
                                0
                                Изучаю Scala на данный момент… Поначалу казалось что все очень здорово и радужно… Сейчас что-то уже страшно. Синтаксис порой просто чудовищен… например, сеттеры для свойств класса:
                                def property_= = property
                                


                                Одной из фишек является возможность легкого и быстрого создания DSL. С другой стороны, когда дело дошло до использования этих самых DSL в своем коде, мне стало жутко неудобно… Каждый перефигачивает операторы как хочет, из-за чего код превращается в жуткую кашу…

                                Изучать продолжаю, но уже не так все радостно… Все больше напоминает Perl, только на JVM :(
                                  0
                                  Уж не с Lift'ом ли вы познакомились?
                                    0
                                    Вообще, начал изучать Скалу как раз чтобы к лифту подобраться. Чуть-чуть пощупал лифт. Сразу же убило то место, где прямо в коде начинается иммитация html / xml, реализованная через DSL.

                                    Если у вас есть опыт, полезные ссылки и книжки, буду очень признателен :) (можно в личку)
                                  +1
                                  Ну, кстати, создатель Джавы (Джеймс Гослинг) тоже с вами в чем-то согласен.
                                  0
                                  Да, отличный язык для скриптинга, тестов и ДСЛ. Возможно (экспериментирую) и для остальных вещей.

                                  Добавьте-ка линк: www.asert.com.au/pubs/Groovy/Groovy.pdf
                                    +3
                                    >То есть на Java имеем три метода вида:

                                    Хм… (писал прямо тут, так что возможны ошибки, но общая идея должна быть понятна):

                                    abstract class Criteria {
                                        abstract boolean matches(Employee e);
                                    }
                                    
                                    List getEmployeeWithCriteria(List staff, Criteria criteria) {
                                        List result = new ArrayList();
                                        for (Employee e: staff) {
                                            if (criteria.matches(e)) {
                                                result.add(e);
                                            }
                                        }
                                        return result;
                                    }
                                    
                                    println getStaffWithCriteria(staff, new Criteria(){ boolean matches(Employee e) { return e.salary > 600; } });
                                    println getStaffWithCriteria(staff, new Criteria(){ boolean matches(Employee e) { return e.age < 27; } });
                                    println getStaffWithCriteria(staff, new Criteria(){ boolean matches(Employee e) { return e.dept == 'A1';} });
                                    


                                    Да, кода всё равно чуть больше, чем в Groovy, но не так драматично, как Вы описываете (три одинаковые функции).
                                      0
                                      Ага, слукавил :) Спасибо
                                        0
                                        Да, про классический лимит в 80 символов можно забыть…
                                          –2
                                          И часто Вам приходится просматривать Java-код на текстовом терминале 80x25? :)
                                            0
                                              0
                                              80 нет, но на ноутбучном мониторе максимально развёрнутая консоль при комфортном шрифте даёт символов 100 с небольшим.

                                              Да и дело не только в консоли. Есть почтовые рассылки, есть блоги, есть не очень прямые браузеры репозиториев, иногда надо пользоваться утилитами для мёржинга (я благодаря им полюбил широкоформатные мониторы, ага). Почти везде можно наткнуться на ситуацию, когда полторы сотни символов в ряд не приемлемы.

                                              В моих проектах обычно по соглашению используется ограничение в 120 строк — иначе с Java и сановским стандартом кодирования никак. Не могу сказать что это радует.
                                                0
                                                Ну так 100 — это уже не 80, верно? Да и о каком стиле может идти речь в примере, который даже не скомпилируется? :)

                                                P.S.: у нас в проекте (и в сопутствующих) принято как раз 100, но за лишние 2-3-5 символов никто убивать не будет.
                                          0
                                          Огромный плюс груви по сравнению со Скалой то, что почти любой соурс на Яве будет валидным соурсом на груви. Т.е. не надо тратить время на обучение группы. Если не помнишь как сделать что то красиво in groovy way — всегда можно по явовски.
                                            +1
                                            Если есть валидный сурс на яве — зачем его делать *почти* валидным сурсом на груви?
                                              0
                                              Для реализации динамического деплоймента кода в сервер приложений, например.
                                                0
                                                Не понял идеи. Написать скрипт на груви и использовать в стиле CGI? Сервер ведь жалко.
                                                  0
                                                  а что вы подразумеваете под «CGI-стилем» в данном случае?
                                                    0
                                                    Допустим у вас есть DAO-классы, которые выполняют некоторые запросы к БД. Для того, чтобы что-то в них быстренько поправить, нужно передеплоить приложение целиком. Ну или перезапускать, если у вас не app server, а десктопный свинговый клиент, к примеру. Это неудобно. У меня на работе коллеги написали автоматический деплоер, который подцепляет скрипты из папочки в рантайме. Очень удобно. Причем код, который деплоится в виде скрипта, можно смотреть эклипсом с полноценной подсветкой синтаксиса и интеллисенсом (поскольку IDE может считать его java кодом). Очень удобно для написания скриптов.
                                                      0
                                                      В смысле они компилируются и результатом подменяются старые версии? Но это не связано с груви — решение для самой Java будет точно таким-же. Или я что-то упускаю в способе выполнения груви скриптов?
                                                        0
                                                        А разве джава классы можно подгружать динамически без создания classloader'ов и прочей мутотени?
                                                          0
                                                          Нельзя. Но это связано не с языком, а с самой VM. Мне казалось что для любого языка объём проблем одинаков. Если в груви предприняты какие-то шаги для облегчения процесса интересно узнать :)
                                                            0
                                                            Ну как бэ мы не обсуждаем проблемы языков оторванно от конкретных ситуаций :)
                                                            Груви можно просто взять и подгрузить во время выполнения программы — и в этом вся фишка. Понятное дело, что в остальном разницы особой и нет, если программист не использует вещи, специфичные для груви и программирует так же, как бы программировал на Java. В этом случае груви ему, конечно, ни к чему.
                                                              0
                                                              на groovy, грубо говоря, будет просто eval()
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        Мб, я на самом деле с OSGI не работал, знаю только, что там плагинная система. Но в любом случае написать ручками деплоер скриптов, который периодически сканирует папку и деплоит все что видит, это очень быстро по сравнению с использованием OSGI.
                                                      0
                                                      я к тому, что можно писать на смешанном стиле" пока выучишь все фичеры языка
                                                    +1
                                                    имхо для getStaffWithCriteria лучше было бы использовать grep/findAll
                                                      0
                                                      Угу, дописал. Не думал, что бывает настольно просто. Спасибо.
                                                        0
                                                        ну, если уж упрощать, то можно было б совсем оставить collection.grep {it.salary > 600}
                                                      –3
                                                      Все эти groovy/scala временное явления, как добавят немного синтаксического сахара в 7-8 версию, они особо и нужны не будут.

                                                      И вообще, java это типизированный язык для разработки больших систем, если вам нужны скрипты юзайте заколённый во времени python — потратьте немного времени на изучение и будем вам счастье.
                                                        +2
                                                        >Все эти groovy/scala временное явления, как добавят немного синтаксического сахара в 7-8 версию, они особо и нужны не будут.

                                                        всех фич даже текущего groovy в java7/8 не будет, а ведь в groovy к этому моменту фич станет ещё больше…

                                                        >если вам нужны скрипты юзайте заколённый во времени python — потратьте немного времени на изучение и будем вам счастье.

                                                        вас не затруднит рассказать о плюсах python перед groovy?
                                                          0
                                                          Зачем еще больше фич в синтаксисе? :) Это уже извращение какое-то тогда получится :) Впрочем, видимо вы ловите кайф, когда в язык чего-то только не напихают, типа C#, там даже подобие SQL умудрились воткнуть в синтаксис. Ну чтоже, на вкус и цвет… :)

                                                          Мне нравится больше минимализм в синтаксисе, от того и люблю такие языки как java или недавно вышедший go.

                                                          "! о плюсах python перед groov" — шило на мыло, но зачем плодить сущности? Питона, руби (jython, jruby) было мало?
                                                            0
                                                            >Зачем еще больше фич в синтаксисе?
                                                            для DSL, например: groovyconsole.appspot.com/script/355001
                                                            а вообще фичи groovy — это уже давно не только и не столько «синтаксический сахар», например groovy++ вообще на AST построен

                                                            >типа C#, там даже подобие SQL умудрились воткнуть в синтаксис.
                                                            findAll в groovy вообще всегда был

                                                            >Питона, руби (jython, jruby) было мало?
                                                            jython вообще мёртв, jruby совершенно не совместим по синтаксису с java и привязан к ruby.
                                                        –6
                                                        И еще java это множество хороших библиотек и фреймворк, если же каждый начнёт писать на своём любом язычке (groovy, scale, etc.), то в итоге будет зоопарк… Я уже с этим столкнулся, когда хотел посмотреть сырцы EtherPad… для этого я должен идти учить scala… Ну и нафиг мне это надо? Потом кто-то напишет на clojure. И что, мне теперь идти изучать clojure, чтобы посмотреть сырцы?
                                                          0
                                                          По моему мнению, основы какого-нибудь языка изучаются куда проще, нежеле очередной фреймворк. Почему Вас тогда не смущает обилие фреймворков в Java мире?.. Взять только веб: Spring MVC, Sling, Struts, GWT, Vaadin и можно продолжать еще долго, при том, что не найдем какой-нибудь де-факто.
                                                            0
                                                            Кто сказал, что меня не смущает? Меня смущает GWT — это неверное направление, временная затычка, пока на место JavaScript не придёт новый Ecma стандарт, с блекджеком и шлюхами. Или NativeClient станет популярным.

                                                            Еще раз повторюсь — я (и не только я, есть еще куча умных дядек, пишущие умные книги) считаю, что плодить сущности это плохо. Разнообразие фреймворков и затычек типа GWT — это терпимо. Но когда к этому пихают новые надязыки и позиционируют их как мейнстрим (когда они применимы для узкой области и пару тысяч фенов), то это плохо. Потому что мало знающие или не опытные специалисты ведутся на это и теряют затем кучу времени впустую.
                                                              0
                                                              >Меня смущает GWT — это неверное направление, временная затычка, пока на место JavaScript не придёт новый Ecma стандарт, с блекджеком и шлюхами.

                                                              а что принципиально изменит новый EcmaScript?

                                                              >Но когда к этому пихают новые надязыки и позиционируют их как мейнстрим (когда они применимы для узкой области и пару тысяч фенов), то это плохо. Потому что мало знающие или не опытные специалисты ведутся на это и теряют затем кучу времени впустую.

                                                              вы считаете что groovy — это сильно нишевый «надязык»?
                                                            0
                                                            к слову понять/писать на groovy значительно проще, чем на scala/clojure, и это ещё один из его плюсов
                                                            0
                                                            Я тоже питал восторженные чувства о Groovy, когда изучал его. Сейчас пишем проект на этом блядстве! Пасаны, забудьте — а то кошмары снится будут. И речь даже не в том, что на четыре строчки вышеприведенного скрипта — эта хня сгенерит джава класс в 2 сотни строк (по сравнению с которым класс с 37-ю строками вам покажется очень понятным и легковесным), проблема в написании большого кол-ва кода практически в текстовом блокноте, это я уже не упоминаю про потерю типизации при код-ревью. Вообщем используя груви, можно получить нервное расстройство, много потраченного времени и благополучно заваливающийся проект!!! Груви -ГАВНО, или как еще грят — джава на букву Г!
                                                              0
                                                              а зачем писать в блокноте, когда даже бесплатная IDEA его прекрасно поддерживает?
                                                                0
                                                                я сказал — практически в блокноте. пользуемся плагином под eclipse. поддержка груви там полностью отсутствует (автоматическое расставление кавычек и скобочек при переносе — не в счет!). Не знаю, мож на идее и получше с этим обстоит, поскольку можно с уверенностью говорить, что под eclipse groovy-плагина фактически не существует!
                                                                  0
                                                                  ну, раз уж так принципиально не хотите использовать IDEA — попробуйте STS: www.springsource.com/developer/sts
                                                                    0
                                                                    его родимого и юзаем! )))
                                                                    FYI — это ничто иное как обычная связка eclipse + куча ненужных spring плагинов, groovy плагин — стандартный, там ставится отдельно. Обо всем этом я и говорил!
                                                              0
                                                              Каждому языку — свое применение.
                                                              Groovy:
                                                              — Низкая скорость (http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html)
                                                              — Больiое потребление памяти…

                                                              + Короткое время входа Java программистов в язык
                                                              + Возможность переиспользования наработаного Java кода

                                                              P.S. Намедне пришлось опять Perl'ом заняться. Все то, что ищем в новых языках уже давно написано и используется в Perl-мире: и DSL, и динамика, и ООП… Только все давно оптимизировано и вылизано.

                                                              P.S.S. Как раз 19-го «похоронили» Gradle у себя на проекте в пользу Ant+Ivy+AntContrib. Очень сырой продукт. Мы кучу ошибок исправили, что-то обернули… Последней каплей стала модель самого проекта, когда посмотрел исходники. Несмотря на известные проблемы и недостатки модели Maven в качестве модели приняли именно ее. И потом танцуют с бубном, чтобы исправить родовую травму. Думаю, ко 2-й версии можно будет пользоваться в серьезных проектах, если модель пересмотрят.
                                                                0
                                                                >Думаю, ко 2-й версии можно будет пользоваться в серьезных проектах, если модель пересмотрят.
                                                                ну, 0.9-то только релизнули, поэтому улучшения ещё будут, хотя по поводу модели не уверен.
                                                                опять же Jetbrains подтянется через полгодика

                                                                >P.S.S. Как раз 19-го «похоронили» Gradle у себя на проекте в пользу Ant+Ivy+AntContrib.
                                                                а расскажите подробнее про грабли gradle, а? почему, кстати, не maven?
                                                                0
                                                                Странно, что за 3 года так и не вышла 1-я версия. А текущая такая сырая.

                                                                Про «градли». Как вы яхту назовете, так она и полывет! (с) Капитан Врунгель.
                                                                Кстати, предложил к использованию в наших проектах именно я. Но и не без меня его похоронили.

                                                                1. Отсутствие полной поддержки EAR-архива. Написали сами.
                                                                2. Гора ошибок при использовании кэша вкачестве локального репозитория, чтобы исключить дублирования артифактов и т.д. Когда много артифактов, то проблема места на диске, как ни страно, еще существует. Пофиксили через обертку.
                                                                3. Невозможность задания имени проекта. Это на первый взгляд может показаться, что это мелочи, но в динамичеких проектах с количеством подпроектов (не модулей!) за 40 поддерживать это крайне неудобно.
                                                                4. Жесткое задание версии продукта. Опять же, когда каждый проект живет своей жизнью, то следить за версиями — отдельная тема. С этим уже не стали бороться — не успели.
                                                                5. Отсутствие поддержки в IDE для многих разработчиков стало преградой.
                                                                6. Отсутствие поддержи CI системами подпотило впечатление тоже.

                                                                Странно, что используя Ivy как основу, разработчики не воспользовались основными его преимуществами.

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

                                                                Что касается Maven, лично у меня к нему давняя нелюбовь из-за костности. Я предпочитаю свободу действий, а не предопределенный путь ;-). Для проектов со сложной структурой им пользоваться крайне сложно без собственных плагинов и плясок с бубном. Ошибки плагинов зачатую не дают возможности пользоваться им совсем. Например, release плагин очень нужный и очень глючный.
                                                                  0
                                                                  Интересно, как всё меняется :)
                                                                  Прошло достаточно времени, и ни одного недостатка, из тех, что вы перечисляете, не осталось :)
                                                                  0
                                                                  >Странно, что за 3 года так и не вышла 1-я версия.
                                                                  имхо не так уж и странно

                                                                  1. ну, это всё-таки не такой уж и большой недостаток самого gradle
                                                                  5. ждём JetBrains, в 10.x наверняка будет
                                                                  6. JetBrains уже поддержали. ну и опять же gradlew никто не отменял.

                                                                  >Странно, что используя Ivy как основу, разработчики не воспользовались основными его преимуществами.

                                                                  ну, из ваших 6 пунктов Ivy помог бы в решении только 2, ну может ещё 3-4 частично
                                                                    0
                                                                    1. Это все же очень частая и логичная операция при сборки J2EE-проектов. И при позиционировании себя как build-tool нужно включать поддержку основных технологий.

                                                                    Ivy используется для поддержки зависимостей, версионности и различных конфигураций. Собственно, для чего он и разрабатывался.
                                                                      0
                                                                      Что-то я видимо недопонял по 3му и 4му пунктам…
                                                                      Смотрим API класса Project — www.gradle.org/0.9/docs/javadoc/org/gradle/api/Project.html.
                                                                      Там есть как имя, так и версия. Поясните, пожалуйста, про жесткое задание версий проекта.
                                                                        0
                                                                        1. далеко не все веб-проекты — это «полноценный» j2ee+ear, зачастую хватает war'а

                                                                        ну, для чего Ivy нужен я знаю, вопрос-то в другом был

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое