Groovy как лучшая Java

    Groovy можно использовать по разному — для скриптов, для Grails, для быстрого написания прототипов, для DSL и т.д.

    Меня же Groovy всегда привлекал как улучшенная Java. В самом деле — почти любой Java код будет валидным кодом Groovy — т.е. если не помнишь как что то делать в Groovy-way, можно всегда писать так, как принято в Java, а если помнишь — вот тебе и Closures, и удобные списки, и много других замечательных вещей.

    Единственное, что мешало использовать Groovy для разработки production кода — отсутствие ошибок компиляции в большом числе случаев. Например если вызываешь несуществующий метод, обращаешься к несуществующей переменной и т.д.

    Для многих Groovy фреймворков и библиотек это реально нужно (см. например работу с XML в Groovy), но если я пишу обычный код, мне это серьезно мешает.

    Так вот, наконец в Groovy 2.0 появилась возможность сказать — проверяй в этом классе типы, существование методов и переменных!


    Возьмем, например, такой класс:

    image

    Он комплируется без проблем.

    Но если мы добавим
    @TypeChecked (эта аннотация может быть на классе или методе), то получим ошибки:

    image

    Также проверка автоматически включается, если мы включаем для класса статическую компиляцию аннотацией @CompileStatic:

    image

    Теперь можно будет писать на Groovy всё то, что писалось на Java и не бояться проблем, пропущенных компилятором.

    Полный список проверок можно найти здесь.

    Было бы еще классно, если бы сделали проверку типов по умолчанию, а динамическую типизацию по аннотации…
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 44

      0
      Нда, с дизайном языка явно что-то не так, если можно спокойно компилировать присвоение строки (в данном случае супер-объекта) в переменную, объявленную как int.
        0
        Дело в том, что int у них всегда объект, у них нет примитивов (если я не ошибаюсь).
        Т.е. ему, как и любому классу можно добажить методы, свойства и т.д.
        Любимый пример Groovy DSL:
        5.euro + 4.dollars
          0
          Пусть объект, но это не отменяет того факта, что я могу присвоить int-переменной любое значение. То есть выходит, что:
          int a
          
          и
          def a
          
          одно и тоже?
            0
            C чего вы взяли, что int переменной можно присвоить любое значение?

            Groovy Shell (1.8.6, JVM: 1.6.0_23)
            Type 'help' or '\h' for help.
            ----------------------------------------------------------------------------
            groovy:000> int a = "asdasd";
            ERROR org.codehaus.groovy.runtime.typehandling.GroovyCastException:
            Cannot cast object 'asdasd' with class 'java.lang.String' to class 'int'
            at groovysh_evaluate.run (groovysh_evaluate:2)
              0
              Ну как, вон в статье самый первый пример. Который компилируется без проблем.
                0
                Возможно на groovy 2.0 это работает иначе, но на 1.8.6 у меня не компилируется.
                  +2
                  Не компилируется или падает в рантайме (то, что Вы показали)?
                    +1
                    Извиняюсь, я был немного не прав. Компилируется, но падает в рантайме :(
                      0
                      А какая разница? Присвоить вы всё равно не можете. Разница только когда и где вам об этом сообщают.
                        +2
                        Разница огромная — об ошибке я узнаю на этапе компиляции, или когда оно свалится у клиента
                          0
                          это не отменяет того факта, что я могу присвоить int-переменной любое значение.

                          Нет такого факта. Есть факт, что подобная ошибка может выявиться на более раннем этапе в языках с сильной или строгой статической типизацией. А в языках со слабой типизацией, пускай и со статической, это вообще не ошибка, а фича, даже выявляться нечему.
                            0
                            Согласен, немного неправильно выразился. Это не отменяет того факта, что транслятор разрешает мне присвоить int-переменной любое значение.
                              0
                              Если транслятор языка с сильной типизацией не выявляет таких явных ошибок на этапе компиляции, то это недостаток транслятора, а не дизайна языка. В языках с динамической типизацией в общем случае нельзя узнать типы операндов не выполняя всей программы и транслятор этим заниматься не обязан. То есть в данном случае можно было бы сказать «в используемом трансляторе нет (опционального!) статического анализа кода на возможные ошибки типизации». Язык от этого ни лучше, ни хуже не становится.

                              Более того, если бы такая опция была, то где этому анализу останавливаться? Проверять только присваивания констант переменной? Константных выражений? Выражений, тип которых выводится за одну итерацию анализа типов переменных в выражении? За 100? Обходить ли все возможные ветвления и выдавать ошибку если есть она хотя бы в одной ветви? Игнорировать ли заведомо мёртвый код? А что считать заведомостью? Делать ли какие-то «предположения» о возвращаемых функциями/методами типах или их тоже анализировать? А если в языке есть средства метапрограммирования (изменения приложением собственного кода), то может это вовсе и не ошибка, а «задумка режиссёра» при реализации, например, защиты от копирования?

                              Вот сколько навскидку вопросов может поставить методический подход к желанию чтобы транслятор обнаруживал ошибку по сути рантайма (т. к. язык динамический) в выражении int a = "a" А стоит ли овчинка выделки? Есть ли смысл делать такую сложную опцию в трансляторе или может лучше сделать вместо неё какую оптимизацию результата компиляции или самого процесса? А если вам нужна такая проверка, то, повторюсь, вероятно вы не тот инструмент выбрали.
                0
                На этапе компиляции пропускает, в рантайме падает.

                Я вот думаю — может оно его пропускает потому что можно как то к int добавить правила кастинга? Но я про такой фичер не знаю…

                Да… озадачили Вы меня :)
                  +3
                  Вот такие моменты я ненавижу, когда ещё на этапе компиляции можно отловить потенциальную ошибку, но этого не происходит. Там хоть warning какой-нить выбрасывается?
                    0
                    Пост как раз про то, как избавиться от подобных проблем.
                      0
                      Это понятно, мне не понятно, почему нужно ставить аннотацию, чтоб компилятор показал эту ошибку. Если я вдруг забуду поставить аннотацию, такое свободно уедет в продакшн.
                      Я не отрицаю, возможно это фича языка, но пока никто не объяснил, что это за фича и насколько она полезна по сравнению с потенциальными ошибками.
                        0
                        Фича простая — определение типа выражения динамическое, в рантайме. Это фича всех (известных мне) языков с динамической типизацией, собственно в этом (почти) динамическая типизация и заключается.
                          0
                          Возможно это просто не мой стиль. Мне понятны либо строгая типизация переменных(java, scala...), либо полное её отсутствие (javascript, lua, python...). Такое смешение сбивает с толку, как минимум меня. Хотя это дело привычки, скорее всего.
                            0
                            Python считается как раз языком со строгой типизацией, динамической, но строгой — нет (почти) неявных приведений типов, выражение типа 1 + "1" выдаст ошибку «unsupported operand type(s) for +: 'int' and 'str'» в рантайме. Ошибка по сути та же самая, что выдаст Groovy в случае int a = "a", просто Python изменяет тип левого операнда в присваивании, а Groovy не может, пытается изменить только значение.
            0
            Дело в том, что int у них всегда объект, у них нет примитивов (если я не ошибаюсь).
            Т.е. ему, как и любому классу можно добажить методы, свойства и т.д.
            Любимый пример Groovy DSL:
            5.euro + 4.dollars
              0
              не туда написал
              0
              То есть Idea пока не подсвечивает косяки on-fly? Подождем…
                0
                Нет, я специально проверял в 11ой, которая как заявленно поддерживает Груви 2.0
                +4
                Ваша формулировка аля «улучшенная джава» – это спорно мягко говоря. Groovy – динамический язык, как вы его не маринуйте со всеми Java 7 и invokedynamic, всё равно удар по производительности неизбежен, а вы говорите «улучшенная» – в итоге всё равно возвращаетесь к тому, что хотите type safety.

                Короче говоря Scala вам в руки, а Groovy – это так, игрушки.
                  –2
                  Статиеская компиляция даёт сравнимую с джавой производительность
                  +4
                  В свое время вот эта статья от создателя Groovy решила мой вопрос Scala vs Groovy.

                  Цитата оттуда же:
                  I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
                    0
                    Меня привлекает в Груви, что не надо учить совершенно новый синтакс
                      0
                      Ваша позиция мне понятна, однако не могу согласиться с заголовком статьи, где Groovy позиционируется как лучшая Java.
                        0
                        Как я написал — это одно из возможных использований груви, возможно не основное по замыслу создателей, но очень интересное мне
                        0
                        по мне, единственный плюс groovy — в проекте из 23 разработчиков используется groovy/scala/java, так что знаю о чем говорю :)
                          0
                          А почему?
                        0
                        хыхы, это эпик фейл сделать такое признание :)
                          +2
                          Ну нужно заметить что автор сказал что «ему не пришло бы в голову начать», а не то что оно лучше. Ну и во-вторых он конечно один из основавших, есть в списке фаундеров, но вот найти код который он написал не получается, или утерян или я не знаю. На гитхабе он и не форкнул свое детище даже. А в третих, он уже в Kotlin коммитит :)
                            +2
                            А по-моему, наоборот, хорошо, что чувак может признавать свои ошибки и не закрывать глаза на чужие успехи.
                            Мне он наоборот после этого признания как-то симпатичнее, как человек и инженер стал.
                              0
                              Все верно, да и там он не просто признал превосходство другой «школы», но и обосновал и разложил все по полочкам.
                          0
                          Самая большая проблема Groovy — IDE. Пока не будет нормальной поддержки автодополнения/дебага/подсветки, массы не перейдут к сожалению :(

                            0
                            IDEA отлично делает автодополнение, дебаг и подсветку. В своей бесплатной версии. Эклипс, кажется, тоже
                              0
                              а вот и нифига. Самый последний greclipse является сплошной головной болью. Автодополнение не работает в динамических типах(и не только). Дебаг работает дико и с ошибками. Я уже на говорю о conditional breakpoints и прочих плюшках.

                              В конце концов сильный и гибкий язык не получает распространения из-за проблем среды разработки.
                                0
                                В IDEA 10, 10.5. 11 всё прекрасно работает. Попробуйте
                                  0
                                  Я бы попробовал, но вся компания не будет добалять еще одну среду разработки для одного проекта (который должен интегрироваться с другими существующими).
                                    +2
                                    Ну н интегацию эт не жн виять — би же иет не в IDE, a в maven, ии что там у вас…
                                      0
                                      Не должно влиять
                            0
                            Вот, прям щас ретвитнул:

                            Only users with full accounts can post comments. Log in, please.