У динамического Java-синтаксиса для JVM есть все шансы для перевоплощения в первый стандартизованный язык написания сценариев к Java
Многие мои коллеги разочаровывались, потратив массу времени на попытку устранения ошибки в коде, после чего выяснялось, что источником ошибки был компилятор или же библиотека времени выполнения.
Когда я работал помощником преподавателя в аспирантуре, то, как правило, аспиранты часто жаловались на непредвиденное поведение компилятора при устранении ошибки. Не отрицая наличия жалоб в адрес компиляторов, часто выводящих код с ошибками, я убеждал студентов, что нужно прилагать все возможные усилия и проявлять больше системности в отладке кода, и лишь затем приступать к поиску дефектов компилятора. Этот принцип применялся перед появлением Java. В ранний период работы с Java мне приходилось прилагать массу усилий для борьбы с неисправностями кода в библиотеках JDK, и при первых попытках генерировать оперативный компилятор JIT. И вновь я возвращаюсь в прошлое, когда слышу о проблемах с JIT или же снова переживаю за очередное крушение Java.Мой недавний негативный опыт был связан с библиотеками java.nio в J2SE 1.4. Проблемы касались в основном реализации java.nio на различных платформах в каждой из версий 1.4, включая и последнюю 1.4.2_04 SDK. Несмотря на устранение неполадок java.nio, выборочные операции ввода-вывода с не блокирующимися соединениями не работали. В этой ситуации бессмысленно тратить собственное время на разрешение проблемы. Я сожалею о том, решил воспользоваться Java для сетевого системного программирования. Несмотря на то, что многие из неполадок были продемонстрированы во время Парада Java- неполадок (Java Bug Parade, см. «Дополнительные ресурсы) в сентябре 2003 года, часть из них все еще не исправлена.
Я никогда не был ярым защитником открытого кода для средств Java, однако всегда выступал за Java Community Process (JCP). Самый последний опыт работы с неполадками привел меня к той мысли, что компании Sun необходимо перевести Java технологии в область проектов с открытым доступом к исходным кодам, тем самым облегчив задачу разработчиков по отладке и исправлению неисправностей на всех уровнях. Я ни в коем случае не настаиваю на том, чтобы данные изменения стали общей тенденцией, однако многие разработчики подключают к работе с Java возможности Python на сервере и wxPython - на клиенте. До этого, я рекомендовал Perl для коротких программ, по причине возникших проблем с поддержкой программных средств. Perl 6 может разрешить проблему. Итак, подытожим: языками сценариев расширяют межплатформенные возможности Java что обеспечивает рост их популярности.
1. Единственный в своем роде
Количество языков сценариев растет с каждым годом. Программисты отдают им предпочтение, поскольку для обучения требуется малые усилия, эти языки обеспечивают высокий уровень функциональности, что значительно сокращает время разработки программы, а также, предоставляет возможность «склеивания» разнородных компонентов программы. Для Java уже создавались языки и средства написания сценариев. Среди них - Jython, Jacl, NetRexx, Rhino, BeanShell, JRuby, JudoScript, BSF и Swig. Последние два предназначены для внедрения языков сценариев в программы и предоставления возможностей межъязыкового взаимодействия. Несмотря на наличие уже существующих средств, проект с открытым кодом Groovy (см. «Дополнительные ресурсы) был представлен JSR 241 на рассмотрение JCP. Groovy был направлен на лидерство среди языков написания сценариев под Java.
Самый распространенный вопрос на первых этапах изучения Groovy: «Для чего нам другой язык написания сценариев?» Обоснование создания другого языка написания сценариев дается нелегко, в особенности, если большинство свойств данного языка дублируют свойства уже существующих. Единственным убедительным аргументом, предоставленным командой разработчиков Groovy является тот факт, что синтаксис других языков написания сценариев, таких как Python, отличен от Java. При настройке средств под Java, например, как в случае с Jython, разработчики обращаются к воссозданию всех стандартных библиотек родительского языка вместо того, чтобы воспользоваться корневыми библиотеками Java как бызовыми. Groovy поддерживает синтаксис, максимально приближенный к Java, при этом вводя и различия. Он построен на стандартных библиотеках Java и компилируется в байт-код, облегчая объединение с Java и запуск в JVM.
Документация для Groovy все еще не завершена и не объясняет всех принципов работы языка. Было бы нелишним, если бы JSR 241 выпустил спецификацию языка. На данный момент все еще существует доля неудачных попыток и ошибок при написании сценариев в Groovy, несмотря на это, всегда можно воспользоваться открытым исходным кодом, обратиться за помощью к разработчикам или же подписаться на рассылку. Очень хороший способ ознакомления с новым языком – проработка примеров. В Листинге 1 представлена Java-программа рисования черно-белой шахматной доски в окне регулируемого размера. В Листинге 2 представлен сценарий Groovy, реализующий эту же программу. Давайте рассмотрим, каковы же различия между ними.
В Groovy можно отказаться от использования точки с запятой, что опционально. Для выполнения программы здесь не требуется использование класса инкапсулирования и основного статического метода. Сценарий GroovyCheckerboard компилируется в класс, называемый GroovyCheckerboard с основным статическим методом, содержащим основной сценарий. Примитивные типы не используются в Groovy. Все константы автоматически заключены в прямоугольники, если необходимо объявить тип, который обычно является примитивной переменной, то следует воспользоваться примитивными интерфейсными классами из пакета java.lang – например, целого и логического типа. Я употребил выражение «если необходимо объявить тип», поскольку Groovy динамически типизирован. Необходимость в объявлении типа переменной отпадает, поскольку он определяется в процессе присваивания. Однако, переменную следует объявить перед ее использованием, подобно тому, как фреймы объявляются перед использованием в замыкании (closure) слушателя (см. Листинг 2).
2. Особенности Groovy
Все классы и объявления членов автоматически являются общими. При необходимости ограничения доступа к классу или члену, его необходимо объявить как защищенный (protected), либо как частный (private). Однако, непосредственный доступ к общим и защищенным переменным закрыт. Их можно преобразовать в частные переменные с соответствующими общими или защищенными методами getter и setter. Поэтому такие объекты Groovy, как JavaBean и его члены являются свойствами. Несмотря на то, что синтаксис Groovy для получения доступа к переменной экземпляра такой же, как и в Java, то выражение:
object.property = value
трансформируется в:
object.setProperty(value)
Объекты Java с методами setter и getter рассматриваются как доступные свойства, что можно записать как:
frame.visible = true вместо: frame.setVisible(true)
а также, проинициализировать board посредством рассмотрения boardSize как свойство (см. Листинг 2). Множество действий в Groovy можно осуществить как и в Java, но всегда существует способ, характерный только Groovy (иногда даже более, чем один). Возможность использования различных синтаксических форм для выполнения той же самой операции, может усложнить понимание сценариев Groovy. Философия Perl, провозглашающая «наличие нескольких способов выполнения операции», проявила как свою благотворность, так и разрушительность. Тот, кто находит ее банальной, обычно переходит на Python.
Два самых полезных свойства Groovy – собственный синтаксис для списков и карт и поддержка замыканий. Поддержка списков и замыканий тянет за собой уже ранее задаваемый вопрос: «А почему бы нам не программировать в Lisp или Scheme?» (операторы возврата тоже опциональны в Groovy). В подпбных условиях значительно снижается мотивация последующего создания новых языков написания сценариев. Списки Groovy поддерживают несколько операций, что значительно облегчает работу с ними. Например, использование списка и замыкания выводит на печать каждый из элементов списка:
[ "hunt", "the", "wumpus" ].each
{ println it }
Конечно же, скобки являются опциональными в таких вызовах методов как активизация println. Аналогично этому, каждая кнопка и каждое значение клавиши будут выведены на печать.
[ "instrument" : "guitar" ,
"model" : "Les Paul Custom"
].each { println "key:
${it.key} value: ${it.value}"
}
В строке можно установить переменные, как в случае с аргументом и println.
Замыкания в двух предыдущих примерах используют неявный параметр it. Можно объявить параметры замыканий в присвоении слушателю (см. Листинг 2). Если читатель хоть немного знаком с Lisp, то можно увидеть, что замыкание напоминает лямбда-выражение. В Java самым близким к замыканию является анонимный внутренний класс. Замыкания Groovy являются истинными с той позиции, что они выпускают локальные переменные, используемые внутри замыкания, за его пределы. Если вы хотите возвратить замыкания из функции, то при каждой попытке использования связываний переменных, характерных для местного контекста вызова функции, будут появляться различные экземпляры. Кроме этого, замыкания реализуются как объекты, которые можно активизировать и присвоить переменным.