Представлен (https://blogs.apache.org/logging/entry/announce-apache-groov...) релиз языка программирования Groovy 2.5 (http://groovy.apache.org/), который с 2015 года развивается под эгидой Фонда Apache. Язык Groovy заимствовал некоторые полезные качества Ruby, Haskell и Python, но создан для работы внутри виртуальной машины Java (JVM) и поддерживает тесную интеграцию с Java-приложениями. За годы существования Groovy вокруг данного языка сформировалась экосистема из связанных проектов, таких как MVC web-фреймворк Grails (http://grails.org/), swing-ориентированный фреймворк Griffon (http://griffon-framework.org/), системы сборки Gant (https://gant.github.io/) и Gradle (http://gradle.org/), инструментарий для интеграции с Google App Engine - Gaelyk (http://gaelyk.appspot.com/), система параллельного программирования Gpars (http://www.gpars.org/), тестовый комплект Spock (http://www.spockframework.org/), инструменты для контроля качества CodeNarc (http://codenarc.sourceforge.net/) и GMetrics (http://gmetrics.sourceforge.net/).
В новом выпуске исправлено более 300 ошибок (http://groovy-lang.org/changelogs/changelog-2.5.0.html) и добавлено более 100 улучшений. Среди наиболее значительных новшеств (http://groovy-lang.org/releasenotes/groovy-2.5.html) поддержка макросов, в форме которых можно определять выражения, операторы, методы и классы. В выпуске также представлено 11 новых AST-преобразований (@AutoFinal, @AutoImplement, @NamedParam, @MapConstructor и т.п.) и обеспечена возможность использования повторяющихся аннотаций. В утилиты groovy и groovyConsole добавлена поддержка прямого запуска тестов jUnit 5. Переработан CliBuilder, в котором добавлена возможность задания определений в стиле аннотаций и обеспечена поддержка Commons CLI и Picocli. Повышены требования к JDK: для сборки теперь необходим JDK8+, а в качестве минимальной версии JRE заявлен JDK7.URL: https://blogs.apache.org/logging/entry/announce-apache-groov...
Новость: https://www.opennet.me/opennews/art.shtml?num=48686
Кто работает с Groovy, пациент скорее жив или скорее мёртв? В смысле, начинает ли кто-нибудь новый проект на Groovy в 2018 году? Или хотя бы в 2017?
Поделитесь, правда интересно.
Я на AWK небольшой скрипт написал в 2018 году, так что я думаю нормально, главное ж не это. Главное чтобы инструмент подходил под задачу.
где бы взять этих задач, под которые groovy подходит :)
Он бы может много по что подходил, если бы у него была более предсказуемая семантика по отношению к синтаксису.Одни только неработающие private чего стоит, причем очень запутанное объяснение, что типа эта такая фича, что private - это как бы не private, а обертка для геттеров/сеттеров (или что-то в этом роде). Ну так и назвали бы это property, а ограничения доступа вообще бы не вводили никак, если не знают как это реализовать.
> если не знают как это реализовать.А зачем им знать - это JVM реализовывает.
Вот только повальное увлечение этим от лукавого. Хотя особо упертые пытаются прибить Unsafe и иже с ним в той же кофеварке.
>> если не знают как это реализовать.
>
> А зачем им знать - это JVM реализовывает.Так и я о том же. Если не знают, как это JVM реализовывает, тогда и не надо реализовывать, то что должна реализовывать VM. Или уж так, чтоб работало, как ожидается.
Если сказано "private" - это должно быть именно "private", как во всех других языках.
А не что-то другое, типа, попробовали, не поняли, как "это JVM реализовывает", пусть тогда это у нас будет так, как она это реализовывает, не понятно как, но пусть это ключевое слово остается, и все думают, что у нас все по настоящему... а когда кто-то докопается, скажем, что это такая фича, а остальные и так схавают.
> Вот только повальное увлечение этим от лукавого. Хотя особо упертые пытаются прибить Unsafe и иже с ним в той же кофеварке.
А это тут причем? О том и речь, не получается без Unsafe - ну и лучше вообще не делать. Иначе уж делать до конца, с полным понимаем и гарантированной поддержкой.
Начинать, может, и не надо, а вот поддерживать много где, бо много где встроен как скриптовой язык - тот же Gradle и т.д.
В Gradle вроде будут переходить на Kotlin, поэтому учить Groovy из-за него не стоит.
> В Gradle вроде будут переходить на Kotlin, поэтому учить Groovy из-за него не стоит.Ух ты! Было бы круто!
Это где такая новость?
И сколько десятилетий на это запланировано? )))Так и ждал, что на Kotlin будут делать подобное (правда думал, что это будет отдельный проект, а не в рамках Градл, а то они так от зависимостей Градла никогда не избавятся).
> Это где такая новость?
> И сколько десятилетий на это запланировано? )))https://blog.gradle.org/kotlin-meets-gradle
Всё уже как-то работает, но официально оно пока experimental.
> В Gradle вроде будут переходить на Kotlin,
>
>> Это где такая новость?
>> И сколько десятилетий на это запланировано? )))
>>
> https://blog.gradle.org/kotlin-meets-gradle
>
> Всё уже как-то работает, но официально оно пока experimental.Нуу, это всего лишь типа Kotlin scripting support.
Это не то же самое, что "переходить на Kotlin".
Вот когда будет что-то вроде "Kotlin build tool" целиком...
(Это не в укор Kotlin, просто действительно аналог Мавена на Kotlin было бы гораздо лучше, чем на этом кривом и тормозном Groovy.)
Groovy широко используется в Jenkins 2.+ CI для написания пайплайнов где-то с 2016, и чем дальше в лес - тем толще партизаны. так что оно живее многих живых. https://jenkins.io/2.0/#pipelines
> Groovy широко используется в Jenkins 2.+ CI для написания пайплайнов где-то с
> 2016, и чем дальше в лес - тем толще партизаны. так
> что оно живее многих живых. https://jenkins.io/2.0/#pipelinesНапиши ещё побольше этих пайплайнов, и тогда ты возможно захочешь переехать куда-то с убогого дженкинса
и где в опенсорсе сейчас можно неубого задать инструкции сборкив виде файла? чтобы не просто список команд необходимых для сборки, как в баш скрипте написать аля трэвис и выбрать тип воркера для выполнения, а реально настроить триггеры, доступ к определенному рсшаренному кейрингу для определенных ступеней сборки и т.д. и т.п.
Если устраивает JVM как платформа, то лучше на Kotlin
Kotlin надо гальванизировать, чтобы ожил наконец, - 7 лет как бы развивается, но до сих пор тестовая версия и популярен в узком кругу в качестве игрушки.
Про популярность странно слышать от сторонника BSD.И с чего это тестовая версия? Давно уже не тестовая.
Добро пожаловать в 2018-й. Гугл год или два как уже топит за разработку под андроид на Котлин. Последний Google I/O, который недавно был - всё под андроид на Котлин показывали.
> Добро пожаловать в 2018-й. Гугл год или два как уже топит за разработку под андроид на Котлин.Все вроде так, только когда слишком увлекаются сленгом, бывает двусмысленно.
Что значит "Гугл топит"?
"Казнить нельзя помиловать"?
> Последний Google I/O, который недавно был - всё под андроид на Котлин показывали.
Это в смысле "утопили", "втопили" или просто "топили за"?
Spock — это фреймворк богов. Чище и понятнее тестов не видел. Писать — одно удовольствие. И динамическая типизация в тестах очень помогает.Продакшн код писать, пожалуй, не стал бы. Как упомянули — котлин или скала — это будет проще, выразительнее, с большим сообществом.
Аналогично. Основной код на Java, тесты все на Groovy.
Динамическая типизация это ловушка в которую попадает каждая вторая муха, все программисты не знающие тип своих переменных\объектов должны отправиться на марс первым туристическим кораблем.
> Динамическая типизация это ловушка в которую попадает каждая вторая муха, все программисты
> не знающие тип своих переменных\объектов должны отправиться на марс первым туристическим
> кораблем.Комментаторы, которые не умеют читать и триггерятся по словосочетанию из двух слов, должны отправиться на марс.
Если я пишу тест для своего же кода на статически типизированном языке, то уж я-то точно знаю типы.
У нас фильтры в log4j на груви. Норм штука, жизнь упрощает. Но вот их компилер не умеет с аспектами в джаве жить :(
Groovy - не смог, теперь есть kotlin который работает в native, wasm, js и jvm
Являясь официальным языком android studio имея богатейший тулчейн оставляет очень мало шансов повторить свой успех groovy и scala.
груви и пр. надо когда четкие ребята пишут четенько на джаве ядро программы, но нужно нанять дешевую рабсилу писать всякую бизнес-логику или типа плагины, вот тогда вот груви и имеет смысла полностью писать проект на груви -- не могу понять, какая именно причина может к этому побудить