Безопасно ли использовать Project Lombok? [закрыто]

В случае, если вы не знаете, Project Lombok помогает с некоторыми неудобствами Java в таких вещах, как генерация геттеров и сеттеров с аннотациями и даже простая генерация JavaBean с @Data . Это может действительно помочь мне, особенно в 50 различных объектах событий, где у вас есть до 7 различных полей, которые необходимо построить и скрыть с помощью геттеров. Я мог бы удалить почти тысячу строк кода с этим.

Тем не менее, я обеспокоен тем, что в конечном итоге это будет печальное решение. Flamewars вспыхнет в ##Java Freenodeканале, когда я упомяну это, предоставляя фрагменты кода, чтобы запутать возможных помощников, люди будут жаловаться на отсутствие JavaDoc , и будущие коммиттеры могут в любом случае просто удалить все это. Мне бы очень понравилось позитивное, но я беспокоюсь о негативном.

Итак: безопасно ли использовать Lombok в любом проекте, маленьком или большом? Стоят ли положительные эффекты отрицательных?

Похоже, вы уже решили, что Project Lombok дает вам значительные технические преимущества для предложенного вами нового проекта. (Чтобы было ясно с самого начала, у меня нет особых взглядов на Project Lombok, так или иначе.)

Прежде чем использовать Project Lombok (или любую другую технологию, изменяющую игру) в каком-либо проекте (с открытым исходным кодом или иным способом), необходимо убедиться, что заинтересованные стороны проекта согласны с этим. Сюда входят разработчики и любые важные пользователи (например, официальные или неофициальные спонсоры).

Вы упоминаете эти потенциальные проблемы:

Flamewars разразятся на канале ## Java Freenode, когда я упомяну это,

Легко. Игнорировать / не участвовать в флеймворах или просто не упоминать Ломбок.

предоставление фрагментов кода может сбить с толку возможных помощников,

Если стратегия проекта заключается в использовании Lombok, то возможные помощники должны будут привыкнуть к нему.

люди будут жаловаться на отсутствие JavaDoc,

Это их проблема. Никто в здравом уме не пытается жестко применять правила исходного кода / документации своей организации к стороннему программному обеспечению с открытым исходным кодом. Команда проекта должна иметь возможность устанавливать стандарты исходного кода / документации проекта, соответствующие используемой технологии.

( FOLLOWUP - разработчики Lombok признают, что проблема заключается не в создании комментариев javadoc для синтезированных методов получения и установки. Если это является серьезной проблемой для вашего проекта (-ов), то одной из альтернатив является создание и отправка исправления Lombok для решения этой проблемы. )

и будущие коммитеры могут просто удалить все это в любом случае.

Это не на! Если согласованная стратегия проекта заключается в использовании Lombok, то комментаторы, которые безвозмездно де-Ломбок кодируют, должны быть подвергнуты наказанию, и, если необходимо, их права на фиксацию отозваны.

Конечно, это предполагает, что у вас есть заинтересованные стороны ... включая разработчиков. И это предполагает, что вы готовы отстаивать свою причину и надлежащим образом обрабатывать неизбежные несогласные голоса.

Просто начал использовать Lombok сегодня. Пока что мне это нравится, но один недостаток, который я не заметил, это рефакторинг поддержки.

Если у вас есть аннотированный класс @Data, он сгенерирует для вас методы получения и установки на основе имен полей. Если вы используете один из этих методов получения в другом классе, а затем решите, что поле имеет неправильное имя, он не найдет использование этих методов получения и установки и заменит старое имя новым именем.

Я полагаю, что это должно быть сделано через плагин IDE, а не через Lombok.

ОБНОВЛЕНИЕ (22 января '13)
После трех месяцев использования Lombok я все еще рекомендую его для большинства проектов. Однако я обнаружил еще один недостаток, аналогичный указанному выше.

Если у вас есть класс, скажем MyCompoundObject.java, у которого есть 2 члена, оба с аннотацией @Delegate, скажем, myWidgetsи myGadgets, когда вы звоните myCompoundObject.getThingies()из другого класса, невозможно узнать, делегирует ли он класс Widgetили, Gadgetпотому что вы больше не можете переходить к источнику в IDE.

Использование Eclipse «Generate Delegate Methods ...» предоставляет вам ту же функциональность, так же быстро и обеспечивает переход к исходному тексту. Недостатком является то, что он загромождает ваш исходный код стандартным кодом, который отвлекает внимание от важных вещей.

ОБНОВЛЕНИЕ 2 (26 февраля '13)
Через 5 месяцев мы все еще используем Lombok, но у меня есть некоторые другие неприятности. Отсутствие заявленного getter & setter может раздражать, когда вы пытаетесь ознакомиться с новым кодом.

Например, если я вижу вызываемый метод, getDynamicCols()но я не знаю, о чем он, у меня есть несколько дополнительных препятствий для перехода, чтобы определить цель этого метода. Некоторые из препятствий - это Lombok, а некоторые - отсутствие умного плагина Lombok. Препятствия включают в себя:

• Отсутствие JavaDocs. Если я сделаю javadoc в поле, я надеюсь, что получатель и установщик унаследуют этот javadoc на этапе компиляции Lombok.
• Переход к определению метода возвращает меня к классу, но не к тому свойству, которое генерирует геттер. Это проблема с плагином.
• Очевидно, что вы не сможете установить точку останова в методе получения / установки, если вы не сгенерируете или не закодируете метод.
• ПРИМЕЧАНИЕ: этот поиск ссылок не является проблемой, как я сначала думал, что это было. Тем не менее, вам нужно использовать перспективу, которая включает представление Outline. Не проблема для большинства разработчиков. Моя проблема была в том, что я использовал Mylyn, который фильтровал мой Outlineвзгляд, поэтому я не видел методы. Отсутствие поиска литературы. Если я хочу узнать, кто звонит getDynamicCols(args...), я должен сгенерировать или закодировать установщик, чтобы иметь возможность искать ссылки.

ОБНОВЛЕНИЕ 3 (7 марта '13)
Я полагаю, научиться использовать различные способы ведения дел в Eclipse. На самом деле вы можете установить условную точку останова (BP) для метода, сгенерированного Lombok. Используя Outlineпредставление, вы можете щелкнуть правой кнопкой мыши на метод Toggle Method Breakpoint. Затем, когда вы нажмете на BP, вы можете использовать представление отладки, Variablesчтобы увидеть, как сгенерированный метод назвал параметры (обычно совпадает с именем поля), и, наконец, использовать Breakpointsпредставление, чтобы щелкнуть правой кнопкой мыши по BP и выбрать, Breakpoint Properties...чтобы добавить условие. Ницца.

ОБНОВЛЕНИЕ 4 (16 августа '13)
Netbeans не нравится, когда вы обновляете свои зависимости Lombok в вашем Maven pom. Проект все еще компилируется, но файлы помечаются как имеющие ошибки компиляции, потому что он не может видеть методы, которые создает Lombok. Очистка кеша Netbeans решает проблему. Не уверен, есть ли опция «Чистый проект», как в Eclipse. Незначительная проблема, но хотел сделать это известным.

ОБНОВЛЕНИЕ 5 (17 января '14)
Ломбок не всегда хорошо играет с Groovy, или, по крайней мере, с groovy-eclipse-compiler. Возможно, вам придется понизить вашу версию компилятора. Maven Groovy и Java + Ломбок

ОБНОВЛЕНИЕ 6 (26 июня '14)
Слово предупреждения. Lombok немного затягивает, и если вы работаете над проектом, в котором по какой-то причине вы не можете его использовать, это вас раздражает. Возможно, вам будет лучше, если вы вообще никогда его не используете.

ОБНОВЛЕНИЕ 7 (23 июля '14)
Это немного интересное обновление, потому что оно напрямую касается безопасности принятия Lombok, о котором спрашивал OP.

Начиная с версии 1.14 @Delegateаннотация переведена в экспериментальный статус. Подробности документированы на их сайте ( Документы для делегатов Lombok ).

Дело в том, что, если вы использовали эту функцию, ваши возможности возврата ограничены. Я вижу варианты как:

• Удалите @Delegateаннотации вручную и сгенерируйте / закодируйте код делегата. Это немного сложнее, если вы использовали атрибуты в аннотации.
• Деломбок файлы, которые имеют @Delegateаннотацию и, возможно, добавляют обратно в аннотации, которые вы хотите.
• Никогда не обновляйте Lombok и не поддерживайте форк (или используйте живые, используя экспериментальные функции).
• Деломбок весь ваш проект и перестаньте использовать Ломбок.

Насколько я могу судить, у Delombok нет возможности удалить подмножество аннотаций ; это все или ничего, по крайней мере, для контекста одного файла. Я открыл билет, чтобы запросить эту функцию с флагами Delombok, но я не ожидал, что в ближайшем будущем.

ОБНОВЛЕНИЕ 8 (20 октября '14)
Если это вариант для вас, Groovy предлагает большинство тех же преимуществ Lombok, а также множество других функций, включая @Delegate . Если вы думаете, что вам будет сложно продать идею властям, посмотрите на аннотацию @CompileStaticили, @TypeCheckedчтобы понять, может ли это помочь вашему делу. На самом деле основной целью релиза Groovy 2.0 была статическая безопасность .

ОБНОВЛЕНИЕ 9 (1 сентября '15)
Ломбок все еще активно поддерживается и совершенствуется , что предвещает хороший уровень усыновления. В @Builder аннотации один из моих любимых новых возможностей.

ОБНОВЛЕНИЕ 10 (17 ноября '15)
Это может показаться не напрямую связанным с вопросом ОП, но стоит поделиться. Если вы ищете инструменты, которые помогут вам уменьшить объем стандартного кода, который вы пишете, вы также можете проверить Google Auto - в частности AutoValue . Если вы посмотрите на их слайд-колоду , перечислите Lombok как возможное решение проблемы, которую они пытаются решить. Минусы, которые они перечисляют для Lombok:

• Вставленный код невидим (вы не можете «увидеть» методы, которые он генерирует) [редактировать примечание - на самом деле вы можете, но это просто требует декомпилятора]
• Взломы компилятора нестандартны и хрупки
• «На наш взгляд, ваш код больше не является Java»

Я не уверен, насколько я согласен с их оценкой. И учитывая минусы AutoValue, которые описаны в слайдах, я буду придерживаться Lombok (если Groovy не вариант).

ОБНОВЛЕНИЕ 11 (февраль 8 '16)
Я узнал, что у Spring Roo есть некоторые подобные аннотации . Я был немного удивлен, обнаружив, что Roo все еще есть, а поиск документации для аннотаций немного грубоват. Удаление также выглядит не так просто, как де-ломбок. Ломбок кажется более безопасным выбором.

ОБНОВЛЕНИЕ 12 (17 февраля '16).
Пытаясь найти обоснование того, почему безопасно привезти Ломбок для проекта, над которым я сейчас работаю, я обнаружил кусок золота, который был добавлен с v1.14- Система конфигурации ! Это означает, что вы можете настроить проект так, чтобы запретить определенные функции, которые ваша команда считает небезопасными или нежелательными. Более того, он также может создавать специфичные для каталога конфигурации с различными настройками. Это круто.

ОБНОВЛЕНИЕ 13 (4 октября '16)
Если подобные вещи важны для вас, Оливер Гирке счел безопасным добавить Lombok в Spring Data Rest .

ОБНОВЛЕНИЕ 14 (26 сентября 17 года).
Как отмечает @gavenkoa в комментариях к вопросу о OP, поддержка компилятора JDK9 пока недоступна (выпуск № 985). Похоже, что команде Ломбок будет нелегко обойтись.

ОБНОВЛЕНИЕ 15 (26 марта '18)
Журнал изменений Lombok указывает на v1.16.20 « Компиляция lombok на JDK1.9 теперь возможна », хотя # 985 все еще открыт.

Однако изменения в соответствии с JDK9 потребовали некоторых серьезных изменений; все изолированные для изменений в конфигурации по умолчанию. Немного по поводу того, что они внесли критические изменения, но версия только повысила «инкрементный» номер версии (переход от v1.16.18 к v1.16.20). Поскольку этот пост был о безопасности, если у вас была yarn/npmпохожая система сборки, которая автоматически обновлялась до последней инкрементной версии, вас могло бы ожидать грубое пробуждение.

ОБНОВЛЕНИЕ 16 (9 января '19)

Кажется, проблемы с JDK9 были решены , и, насколько я могу судить, Lombok работает с JDK10 и даже с JDK11.

Одна вещь, которую я заметил, хотя это касалось аспекта безопасности, это то, что журнал изменений, переходящий с v1.18.2 на v1.18.4, перечисляет два элемента как BREAKING CHANGE!? Я не уверен, как происходит критическое изменение в обновлении "патча". Может быть проблема, если вы используете инструмент, который автоматически обновляет версии патча.

Продолжайте и используйте Lombok, вы можете при необходимости «delombok» ваш код впоследствии http://projectlombok.org/features/delombok.html

Лично (и, следовательно, субъективно) я обнаружил, что использование Lombok делает мой код более выразительным о том, чего я пытаюсь достичь, по сравнению с реализациями IDE / собственных сложных методов, таких как hashcode & equals.

Когда используешь

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

гораздо проще поддерживать Equals & HashCode и отслеживать, какие поля оцениваются, чем любую IDE / собственную реализацию. Это особенно верно, когда вы все еще регулярно добавляете / удаляете поля.

То же самое касается @ToStringаннотации и ее параметров, которые четко сообщают о желаемом поведении относительно включенных / исключенных полей, использования геттеров или доступа к полям, а также о том, вызывать или не вызывать super.toString().

И снова, аннотируя целый класс с помощью @Getterили @Setter(AccessLevel.NONE)(и, возможно, переопределяя любые расходящиеся методы), сразу становится ясно, какие методы будут доступны для полей.

Преимущества продолжаются и продолжаются ..

На мой взгляд, речь идет не о сокращении кода, а о четком сообщении того, чего вы хотите достичь, а не о том, чтобы выяснить это с помощью Javadoc или реализаций. Сокращенный код облегчает обнаружение любых реализаций расходящихся методов.

Ломбок отличный, но ...

Lombok нарушает правила обработки аннотаций тем, что не генерирует новые исходные файлы. Это означает, что он не может использоваться с другими процессорами аннотаций, если они ожидают, что получатели / установщики или что-то еще существует.

Обработка аннотации проходит в серии раундов. В каждом раунде каждый получает по очереди. Если какие-либо новые файлы Java будут найдены после завершения раунда, начинается новый раунд. Таким образом, порядок обработки аннотаций не имеет значения, если они генерируют только новые файлы. Поскольку lombok не генерирует никаких новых файлов, новые раунды не запускаются, поэтому некоторые точки доступа, основанные на коде lombok, не работают должным образом. Это было огромным источником боли для меня при использовании mapstruct, и delombok-ing не является полезным вариантом, поскольку он уничтожает ваши номера строк в журналах.

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

Я прочитал некоторые мнения о Ломбоке и фактически использую его в некоторых проектах.

Что ж, при первом контакте с Ломбоком у меня сложилось плохое впечатление. Через несколько недель мне это понравилось. Но через несколько месяцев я обнаружил множество мелких проблем с его использованием. Итак, моё последнее впечатление о Ломбоке не так положительно.

Мои причины думать так:

• Зависимость плагина IDE . Поддержка IDE для Lombok осуществляется через плагины. Даже работая хорошо в большинстве случаев, вы всегда являетесь заложником этих плагинов, которые будут поддерживаться в будущих выпусках IDE и даже языковой версии (Java 10+ ускорит развитие языка). Например, я попытался обновить Intellij IDEA 2017.3 до 2018.1 и не смог этого сделать, потому что возникла некоторая проблема с актуальной версией плагина lombok, и мне нужно было дождаться обновления плагина ... Это также проблема, если вы хотел бы использовать более альтернативную среду разработки, в которой нет поддержки плагинов Lombok.
• Проблема «найти использования». , Используя Lombok, вы не видите сгенерированные методы getter, setter, constructor, builder и т. Д. Итак, если вы планируете выяснить, где эти методы используются в вашем проекте вашей IDE, вы не можете сделать это, только глядя для класса, которому принадлежат эти скрытые методы.
• Настолько легко, что разработчики не хотят нарушать инкапсуляцию . Я знаю, что это не проблема с Ломбоком. Но я увидел большую тенденцию разработчиков больше не контролировать, какие методы должны быть видны или нет. Так, часто они просто копируют и вставляют @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorблок аннотаций, не задумываясь о том, какие методы классу действительно нужно предоставить.
• Строитель Obssession ©. Я придумал это имя (отстань, Мартин Фаулер). Помимо всего прочего, Builder настолько прост в создании, что даже когда у класса есть только два параметра, разработчики предпочитают использовать @Builderвместо конструктора или статического конструктора метод. Иногда они даже пытаются создать Builder внутри Lombok Builder, создавая такие странные ситуации, как MyClass.builder().name("Name").build().create().
• Барьеры при рефакторинге . Если вы используете, например, a @AllArgsConstructorи вам нужно добавить еще один параметр в конструктор, IDE не может помочь вам добавить этот дополнительный параметр во всех местах (в основном, в тестах), в которых создается экземпляр класса.
• Смешивание Ломбок с конкретными методами . Вы не можете использовать Lombok во всех сценариях для создания getter / setter / etc. Итак, вы увидите, что эти два подхода смешаны в вашем коде. Вы привыкаете к этому через некоторое время, но чувствуете, как хак на языке.

Как сказал другой ответ, если вы недовольны многословием Java и используете Lombok, попробуйте Kotlin.

Есть и долгосрочные риски обслуживания. Во-первых, я бы рекомендовал прочитать о том, как на самом деле работает Lombok, например, некоторые ответы его разработчиков здесь .

Официальный сайт также содержит список недостатков , в том числе цитату из Reinier Zwitserloot:

Это полный взлом. Использование непубличного API. Самонадеянное приведение (зная, что процессор аннотаций, работающий в javac, получит экземпляр JavacAnnotationProcessor, который является внутренней реализацией AnnotationProcessor (интерфейс), который, как оказалось, имеет несколько дополнительных методов, которые используются для получения в реальном времени AST) ,

В Eclipse это возможно хуже (и все же более надежно) - Java-агент используется для внедрения кода в класс грамматики и анализатора Eclipse, который, конечно, является полностью закрытым API и полностью закрыт.

Если бы вы могли делать то, что делает lombok со стандартным API, я бы сделал это таким образом, но вы не можете. Тем не менее, несмотря на это, я разработал плагин eclipse для eclipse v3.5, работающий на java 1.6, и без каких-либо изменений он работал и на eclipse v3.4, работающем на java 1.5, так что он не совсем хрупок.

Таким образом, в то время как Lombok может сэкономить вам некоторое время на разработку, если существует несовместимое с javac обновление (например, устранение уязвимости), Lombok может застрять в старой версии Java, в то время как разработчики борются за то, чтобы обновить их использование. внутренние API. Является ли это серьезным риском, очевидно, зависит от проекта.

Я знаю, что опаздываю, но не могу устоять перед искушением: всем, кто любит Ломбок, тоже стоит взглянуть на Скалу. Многие хорошие идеи, которые вы найдете в Ломбоке, являются частью языка Scala.

На ваш вопрос: определенно проще заставить ваших разработчиков попробовать Lombok, чем Scala. Попробуйте, и если им это нравится, попробуйте Scala.

Как оговорка: я тоже люблю Java!

Я использовал Lombok почти во всех моих проектах в течение одного года, но, к сожалению, удалил его. Вначале это был очень чистый способ разработки, но настроить среду разработки для новых членов команды не так просто и просто. Когда это стало головной болью, я просто удалил это. Но это хорошая работа, и ей нужно больше простоты в настройке.

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

• Что касается ROI, его легко интегрировать, и он не требует изменения кода в своей основной форме. (просто добавив одну аннотацию к вашему классу)

• И, наконец, если вы передумаете, вы можете запустить unlombok или позволить вашей IDE создавать эти сеттеры, геттеры и ctors (о которых, я думаю, никто не спросит, как только они увидят, насколько ясно ваше pojo становится)

Мое мнение о Lombok заключается в том, что он просто предоставляет ярлыки для написания кода Java.
Когда дело доходит до использования ярлыков для написания Java-кода, я бы полагался на такие функции, предоставляемые IDE - как в Eclipse, мы можем перейти в меню Source> Generate Getters and Setters для генерации геттеров и сеттеров.
Я бы не стал полагаться на такую ​​библиотеку, как Lombok:

1. Это загрязняет код с косвенным слоем альтернативного синтаксиса (чтением @Getter, @Setterи т.д. аннотации). Вместо того, чтобы изучать альтернативный синтаксис для Java, я бы переключился на любой другой язык, который изначально предоставляет синтаксис Lombok.
2. Lombok требует использования IDE с поддержкой Lombok для работы с вашим кодом. Эта зависимость представляет значительный риск для любого нетривиального проекта. Достаточно ли ресурсов в проекте Lombok с открытым исходным кодом для поддержки различных версий широкого диапазона доступных в среде Java IDE?
3. Достаточно ли ресурсов в проекте Lombok с открытым исходным кодом для поддержки новых версий Java, которые появятся в будущем?
4. Я также нервничаю из-за того, что Lombok может создавать проблемы совместимости с широко используемыми средами / библиотеками (такими как Spring, Hibernate, Jackson, JUnit, Mockito), которые работают с вашим байтовым кодом во время выполнения.

В общем, я бы не предпочел "оживить" мою Java с помощью Lombok.

Хотел использовать lombok, @ToStringно вскоре столкнулся со случайными ошибками компиляции при перестроении проекта в Intellij IDEA. Пришлось несколько раз нажать компиляцию, прежде чем инкрементная компиляция могла завершиться с успехом.

Пробовал оба lombok 1.12.2 и 0.9.3 с Intellij IDEA 12.1.6 и 13.0 без какого-либо плагина lombok под jdk 1.6.0_39 и 1.6.0_45.

Пришлось вручную копировать сгенерированные методы из источника delomboked и отложить lombok до лучших времен.

Обновить

Проблема возникает только при включенной параллельной компиляции.

Подана проблема: https://github.com/rzwitserloot/lombok/issues/648

Обновить

Мплушников прокомментировал 30 января 2016 года:

В новой версии Intellij таких проблем больше нет. Я думаю, что это может быть закрыто здесь.

Обновить

Я очень рекомендую перейти с Java + Lombok на Kotlin, если это возможно. Поскольку это решило с нуля все проблемы Java, которые Lombok пытается обойти.

Я столкнулся с проблемой с Lombok и Jackson CSV , когда я упорядочил свой объект (Java-бин) в файл CSV, столбцы которого были дублированы, затем я удалил аннотацию @Data Lombok, и маршализация работала нормально.

Я не рекомендую это. Я использовал его, но потом, когда я работал с NetBeans 7.4, он испортил мои коды. Я должен удалить ломбок во всех файлах в моих проектах. Есть деломбок, но как я могу быть уверен, что он не испортит мои коды. Я должен потратить несколько дней, чтобы удалить ломбок и вернуться к обычным стилям Java. Я просто слишком острый ...

Я еще не пробовал использовать Lombok - он / был следующим в моем списке, но, похоже, Java 8 создала для него серьезные проблемы, а работа по исправлению положения все еще продолжалась неделю назад. Мой источник для этого - https://code.google.com/p/projectlombok/issues/detail?id=451 .