Использование Groovy в качестве языка сценариев

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

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

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

ОТВЕТЫ

Ответ 1

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

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()
    }
}

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

Ответ 2

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

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

Ответ 3

Groovy может быть весьма удобен для сценариев. Недавно мне понадобился script для извлечения зависимостей Maven в каталог lib и в итоге появился groovy script. Этот фрагмент анализирует жука и дает вам список банок. Довольно сладкий для анализа 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"
}

Ответ 4

Например, если я хочу сделать некоторые 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).

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

Ответ 5

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

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

Рассмотрим этот короткий фрагмент, чтобы загрузить весь файл в строку:

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.

Ответ 6

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

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

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

Ударьте это в каталог локальных или общих скриптов, и он будет там в будущем.