Можно ли использовать Project Lombok?

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Если у вас есть класс, скажем, 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)
Lombok не всегда хорошо играет с Groovy или, по крайней мере, с groovy-eclipse-compiler. Возможно, вам придется понизить вашу версию компилятора. Maven Groovy и Java + Ломбок

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ 9 (1 сентября 15)
Lombok по-прежнему активно поддерживается и совершенствуется, что предвещает высокий уровень безопасности принятия. Аннотации @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 !? Я не уверен, как происходит критическое изменение в обновлении "патча". Может быть проблема, если вы используете инструмент, который автоматически обновляет версии патча.

Ответ 3

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

Ответ 4

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

При использовании

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

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

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

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

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

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

Ответ 5

Ломбок замечательный, но...

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

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

Ответ 10

Хотел использовать 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 пытается обойти.

Ответ 11

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

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

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

• Зависимость плагина IDE. Поддержка IDE для Lombok осуществляется через плагины. Даже работая большую часть времени, вы всегда являетесь заложником этих плагинов, которые будут поддерживаться в будущих выпусках IDE, и даже языковой версии (Java 10+ ускорит развитие языка). Например, я попытался обновить Intellij IDE 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().
• Барьеры при рефакторинге. Если вы, например, используете @AllArgsConstructor и вам нужно добавить еще один параметр в конструктор, IDE не может помочь вам добавить этот дополнительный параметр во всех местах (в основном, тестах), в которых создается экземпляр класса.
• Смешайте Ломбок с конкретными методами. Вы не можете использовать Lombok во всех сценариях для создания getter/setter/etc. Итак, вы увидите, что эти два подхода смешаны в вашем коде. Вы привыкаете к этому через некоторое время, но чувствуете, как хак на языке.

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

Ответ 12

Мое мнение о 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.

Ответ 13

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

Ответ 14

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

Ответ 15

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