Использование Groovy в качестве языка сценариев - PullRequest
10 голосов
/ 15 апреля 2010

Я предпочитаю использовать языки сценариев для коротких задач, таких как очень простой http-бот, массовый импорт / экспорт данных в / откуда-то и т. Д. И т. Д. ... Простые одноразовые сценарии и простые вещи. Дело в том, что язык сценариев - всего лишь эффективный инструмент для написания быстрых программ. Что касается моего понимания Groovy на данный момент ...

Если бы вы программировали в Groovy и не хотели писать быстрый скрипт, не заставили бы вас вернуться к обычному синтаксису Java (и мы знаем, как это может быть запутано по сравнению с языком сценариев) чтобы сделать что-нибудь более сложное? Например, если я захочу сделать несколько сценариев http, не вернусь ли я сразу к использованию синтаксиса java для вызова Commons HttpClient? Для меня смысл скриптового языка - в быстро набираемых и менее принудительных конструкциях. И вот еще кое-что, не похоже, что есть какой-то стимул для разработки библиотек на основе Groovy, когда уже существует так много хороших java-библиотек, что делает Groovy кажущимся зависимым от Java языком с небольшими возможностями сценариев.

Так что сейчас мне интересно, смогу ли я перейти на Groovy в качестве языка сценариев или продолжать использовать более распространенный язык сценариев, такой как Perl, Python или Ruby.

Ответы [ 6 ]

12 голосов
/ 15 апреля 2010

@ Зомби, позвольте мне показать вам небольшой пример из сценария, который я недавно написал:

def fetch(build, toFile) {
    new FTPClient().with {
        connect ftpServer
        enterLocalPassiveMode()
        login ftpUser, ftpPassword
        changeWorkingDirectory "/var/staging/revision-${build}"
        fileType = FTPClient.BINARY_FILE_TYPE
        toFile.withOutputStream { ostream -> 
            retrieveFile "build-${build}.zip", ostream 
        }
        disconnect()
    }
}

Он использует API-интерфейс commons-net, но я думаю, вы согласитесь, что он имеет более четкий синтаксис, чем сопоставимая Java-программа. Так что я не думаю, что использование API Java отрицательно сказывается на использовании языка сценариев. Более того, он помогает вам использовать имеющиеся у вас знания API Java, поэтому очень прагматичен.

5 голосов
/ 16 апреля 2010

Groovy может быть очень удобен для написания сценариев. Недавно мне понадобился скрипт для извлечения зависимостей Maven в каталог lib, и в итоге я получил скрипт groovy. Этот фрагмент разбирает пом и дает вам список банок. Довольно мило для разбора XML!

#!/usr/bin/env groovy
def pom = new XmlSlurper().parse('pom.xml')
def repo = "${System.env.HOME}/.m2/repository"

pom.dependencies.dependency.each { dep ->
    def jarName = "${dep.artifactId}-${dep.version}.jar"
    def groupPath = dep.groupId.text().replaceAll('\\.', '/')
    def jarPath = "${repo}/${groupPath}/${dep.artifactId}/${dep.version}"
    println "$jarPath/$jarName"
}
5 голосов
/ 15 апреля 2010

Одна из целей Groovy - обеспечить прозрачную совместимость с Java. Groovy - это «зависимый от Java язык со скриптовыми функциями». Однако я не думаю, что эти функции незначительны - в Groovy есть много функций, которых нет в статических языках программирования (таких как Java).

Подводя итог: если вас совсем не волнует Java, используйте язык сценариев более общего назначения, например Python или Perl. Если вы хотите использовать кодовую базу Java в сценарии, Groovy - хороший вариант.

4 голосов
/ 15 апреля 2010

Groovy "из коробки" заменяет большое количество общих классов на более подходящие версии или языковые конструкции, включая классы для XML, HTTP-запросов, доступа к базам данных SQL и регулярным выражениям. Для большинства задач сценариев вам вообще не придется использовать библиотеки Java (хотя у вас все еще будет эта опция). Но если ваш скрипт использует голые библиотеки Java, вы будете намного дальше с Groovy по сравнению с прямой Java. Где Groovy сияет в «клеевом» коде, например настройка структур данных и файлового ввода-вывода.

Карта и список позволяют создавать совместимые с Java списки и карты; обычные объекты Java, которые работают с классами Java. Groovy часто превращает многострочный вызов метода Java с объявлениями переменных и инициализацией в однострочник.

Рассмотрим этот короткий фрагмент для загрузки всего файла в строку:

def fileContents = new File(filename).text

против

String fileContents = "";
try {
    BufferedReader reader = new BufferedReader(new FileInputStream(filename));
    String line = null;
    while ((line = reader.readLine()) != null) {
        text = text + line + "\n";
    }
} catch (IOException e) {
    e.printStackTrace();
}

Обработка исключений часто не является важным фактором в сценариях, и ее удобно игнорировать.

Основным преимуществом Groovy как языка сценариев является прямой и удобный доступ к огромной библиотеке кода Java. Если вам это не нужно, Groovy по-прежнему предоставляет среду сценариев, столь же богатую, как и другие языки, такие как perl, python или ruby.

4 голосов
/ 15 апреля 2010

Например, если я захочу сделать какой-нибудь http-скрипт, разве я не вернусь к использованию синтаксиса Java для вызова Commons HttpClient?

Вы бы "вернулись к использованию Commons HttpClient", но вы бы вызывали его, используя синтаксис Groovy, а не синтаксис Java. Groovy синтаксис намного более компактен, чем синтаксис Java, и поэтому лучше подходит для сценариев. Другими словами, использование библиотек Java в Groovy требует гораздо меньше кода, чем использование библиотек Java в Java.

не похоже, что есть какой-то стимул для разработки библиотек на основе Groovy, когда уже есть так много хороших java-библиотек

Вместо разработки совершенно новой библиотеки, автор библиотеки Groovy часто предоставляет API Groovier для существующей библиотеки Java. Примеры включают в себя конструктор Hibernate, предоставленный Grails, и HTTP Builder (который делегирует Commons HttpClient).

Эти Groovy API предоставляют более компактную и идиоматическую альтернативу прямому использованию Java API.

2 голосов
/ 21 июня 2011

Groovy качает, как только вы освоите очень жесткий синтаксис, вы начнете использовать его для многих вещей, которые вы только что сделали "медленным путем".

На днях я участвовал в дискуссии, которая почему-то задалась вопросом, сколько символов у нас в GUID в одной из наших систем. Вместо того, чтобы просто считать цифры, было проще сделать это:

def str = '92228498-6A2F-DBA2-7A2C-F54B9E607E3A'
int num = 0
str.each {
    num++
}
println num

Измените это в локальной или общей папке скриптов, и она будет там в будущем.

...