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

Question

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

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

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

Answer 1

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

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

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

Flamewars вспыхнет в канале ##Java Freenode, когда я упомяну об этом,

Легко.Игнорируйте / не участвуйте в flamewars или просто воздержитесь от упоминания Ломбока.

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

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

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

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

(ПОСЛЕДУЮЩИЕ ДЕЙСТВИЯ - Разработчики Lombok признают, что отсутствие генерации комментариев javadoc для синтезированных методов получения и установки является проблемой.Если это серьезная проблема для вашего проекта (ов), то одной из альтернатив является создание и отправка патча Lombok для решения этой проблемы.)

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

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

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

Answer 2

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

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

Я бы представлял, что это должно быть сделано через плагин IDE, а не через ломбок.

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

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

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

Обновление 2 (26 февраля '13)
Через 5 месяцев мы все еще используем Ломбок, но у меня есть другие раздражения. Отсутствие объявленного Getter & Setter может иногда раздражать, когда вы пытаетесь ознакомиться с новым кодом.

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

• Отсутствие Javadocs. Если я Javadoc поле, я бы надеюсь, что добитель и установка наследут, что Javadoc через шаг компиляции ломбок.
• Перейти к определению метода подпрыгивает мне в класс, но не свойство, которое породило добычу. Это проблема плагина.
• Очевидно, вы не можете установить точку останова в Getter / Setter, если вы не генерируете или не сработаете метод.
• Примечание: этот справочный поиск не проблема, как я впервые подумал, что это было. Вам нужно использовать перспективу, которая включает вид наброски, хотя. Не проблема для большинства разработчиков. Моя проблема была, я использую mylyn, который фильтровал мой Outline Вид, поэтому я не видел методы. Отсутствие ссылок на поиск. Если я хочу увидеть, кто звонит getDynamicCols(args...), Я должен генерировать или код установки, чтобы иметь возможность искать ссылки.

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

Обновление 4 (16 августа13)
NetBeans не любит это, когда вы обновляете свои зависимости ломбок в своей Maven Pom. Проект по-прежнему компилируется, но файлы попадают в то, что имея ошибки компиляции, потому что он не может видеть методы Lombok. Очистка кеша NetBeans решает проблему. Не уверен, есть ли «чистый проект», например, в Eclipse. Незначительная проблема, но хотела сделать его известным.

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

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

Обновление 7 (23 июля '14)
Это немного интересного обновления, потому что он напрямую обращается к безопасность принятия ломбок, о том, что ОП задал.

Как на V1.14, @Delegate Аннотация была демотена к экспериментальному статусу. Детали документированы на их сайте (Документы делегата Ломбок).

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

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

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

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

Обновление 9 (1 сен 1 '15)
Ломбок все еще активно поддерживается и расширен, который хорошо организован к уровню безопасности усыновления. То @Builder Аннотации - одна из моих любимых новых функций.

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

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

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

Обновление 11 (8 февраля)
я узнал Весенний роума имеет некоторое время Подобные аннотации. Отказ Я был немного удивлен, чтобы выяснить, что ROO по-прежнему - это вещь, и обнаруживая документацию по аннотациям немного грубая. Удаление также не выглядит так легко, как де-ломбок. Ломбок кажется более безопасным выбором.

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

Обновление 13 (4 октября)
Если эта вещь имеет значение для вас, Оливер Гирке чувствовал, что это было безопасно Добавить Lombok до весны данных.

Обновление 14 (26 сентября '17)
Как указано в @gavenkoa В комментариях по вопросу OPS, Поддержка компилятора JDK9 еще не доступна (Выпуск № 985). Это также звучит так, как будто не будет легко исправленным для команды Ломбок, чтобы обойти.

Обновление 15 (26 марта '18)
Lombok Changelog указывает на себя V1.16.20 "Компиляция Ломбок на JDK1.9 теперь возможно" даже не смотря на #985 все еще открыт.

Однако изменение для размещения JDK9 потребовало некоторых изменений в нарушении; Все изолированные для изменений в настройках Config. Немного относится к тому, что они ввели изменения в разрыв, но версия натащила только «инкрементное» номер версии (идет от V1.16.18 до V1.16.20). Так как этот пост был о безопасности, если у вас был yarn/npm Как и система сборки, которая автоматически обновляется до последней инкрементной версии, вы можете быть на грубое пробуждение.

Обновление 16 (9 января '19)

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Это общий взлом. Использование непубличных API. Предположительное литье (зная, что процессор аннотации, работающий в Javac, получит экземпляр JavaCannotationProcessor, который является внутренним внедрением аннотационногопроцессора (интерфейс), который так бывает, имеет пару дополнительных методов, которые используются для достижения живой АСТ) Отказ

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

Так же как отказ от ответственности: мне тоже нравится Java!

Answer 9

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

Answer 10

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

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

• И, если вы измените свой разум, вы можете запустить Unnombok, или позвольте вашему IDE создавать эти поселенцы, Getters и CTORS, (которые, я думаю, никто не попросит, как только они увидят, насколько ясно становится ваш POJO)

Answer 11

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

Пробовал как Lombok 1.12.2 и 0.9.3 с IDELLIJ IDELIJ 12.1.6 и 13.0 без какого плагина Lombok под JDK 1.6.0_39 и 1.6.0_45.

Пришлось вручную скопировать сгенерированные методы от Delomboked Source и поставить Ломбок на удержание до лучших времен.

Обновлять

Проблема происходит только с включенным параллельным компилированием.

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

Обновлять

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

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

Обновлять

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

Answer 12

Мой взять на ломбок в том, что он просто обеспечивает ярлыки для написания Boilerlate Java Code.
Когда дело доходит до использования ярлыков для записи кода Java BOLILERPLATE, я бы полагался на такие функции, предоставленные IDE - как в Eclipse, мы можем перейти к источнику меню> генерировать Getter и Setters для генерации Getter и Setters.
Я бы не полагался на библиотеку, как Ломбок для этого:

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

В целом я бы не предпочел «оживить» мою Java с ломбоком.

Answer 13

Я столкнулся с проблемой с Ломбок и Джексон ЦСВ, Когда я маршалал свой объект (Java Bean) к файлу CSV, столбцы, где дублировали, то я удалил аннотацию @data Lombok и маршализуя работал нормально.

Answer 14

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

Answer 15

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