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

Question

В случае, если вы не знаете, Project Lombok помогает с некоторыми неприятностями Java с такими вещами, как generating getters and setters with annotations и даже simple JavaBean like generation with @Data. Это может действительно помочь мне, особенно в 50 различных объектах событий, где у вас есть до 7 разных полей, которые нужно построить и спрятать с помощью геттеров. Я мог бы удалить почти тысячу строк кода.

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

So: Безопасно ли использовать Lombok для любого проекта, небольшого или большого? Являются ли положительные эффекты отрицательными?

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Преимущества идти дальше и дальше ..

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начиная с версии 1.1, аннотация @Delegate была понижена до уровня эксперимента. Подробности задокументированы на их сайте (Lombok Delegate Docs).

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

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

Насколько я могу судить, Delombok doesn't have an option to remove a subset of annotations; это все или ничего, по крайней мере, для контекста одного файла. Я открыл a ticket to request this feature с флагами Delombok, но я не ожидал этого в ближайшем будущем.

UPDATE 8 (20 октября '14)
Если это вариант для вас, Groovy предлагает те же самые преимущества Ломбок, плюс нагрузка лодки других функций, в том числе @Delegate. Если вы считаете, что вам нелегко продать идею тем, кто будет, взгляните на аннотацию @CompileStatic или @TypeChecked, чтобы узнать, поможет ли это вам. Фактически, the primary focus of the Groovy 2.0 release was static safety.

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

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

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

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

UPDATE 11 (8 февраля '16)
я узнал Spring Roo имеет некоторые similar annotations. Я был немного удивлен, узнав, что Роо все еще есть, и найти документацию для аннотаций немного грубо. Удаление также выглядит не так просто, как де-ломбок. Ломбок кажется более безопасным выбором.

UPDATE 12 (Feb 17 '16)
При попытке придумать оправдания, почему это безопасно, чтобы принести в Ломбках для проекта я сейчас работаю, я нашел кусок золота, который был добавлен с v1.14 - Configuration System! Это означает, что вы можете настроить проект, чтобы запретить определенные функции, которые ваша команда считает небезопасными или нежелательными. Еще лучше, он также может создавать конфигурацию с конкретным каталогом с различными настройками. Это круто.

UPDATE 13 (4 октября '16)
Если такая вещь имеет значение для вас, Oliver Gierke чувствовал, что это было безопасно add Lombok to Spring Data Rest.

UPDATE 14 (Sep 26 '17)
Как отметил @gavenkoa в комментариях по OPS вопросу, JDK9 compiler support isn't yet available. Похоже, что это не будет легким решением для команды Ломбок, чтобы обойти.

Answer 7

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

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

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

Answer 8

Требуется использовать lombok's @ToString, но вскоре возникли случайные ошибки компиляции при перестройке проекта в Intellij IDEA. Если бы компиляция была успешной, нужно было скомпилировать ее несколько раз.

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

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

Update

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

Поданный вопрос: https://github.com/rzwitserloot/lombok/issues/648

Update

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

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

Update

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

Answer 9

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

Answer 10

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

Answer 11

я столкнулся с проблемой с Ломбками и Джексоном CSV, когда я marshalized моего объекта (Java Bean) в файл CSV, столбцы, где дублируются, то я удалил @data аннотации Ломбок и marshalizing работал отлично.

Answer 12

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

Официальный сайт также содержит list of downsides, в том числе это цитата из Reinier Свитсерлоота:

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

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

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

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

Answer 13

Ломбки велики, но ...

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

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

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

Answer 14

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

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

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