В случае, если вы не знаете, Project Lombok помогает с некоторыми неудобствами Java в таких вещах, как генерация геттеров и сеттеров с аннотациями и даже простая генерация JavaBean с @Data . Это может действительно помочь мне, особенно в 50 различных объектах событий, где у вас есть до 7 различных полей, которые необходимо построить и скрыть с помощью геттеров. Я мог бы удалить почти тысячу строк кода с этим.
Тем не менее, я обеспокоен тем, что в конечном итоге это будет печальное решение. Flamewars вспыхнет в ##Java Freenode
канале, когда я упомяну это, предоставляя фрагменты кода, чтобы запутать возможных помощников, люди будут жаловаться на отсутствие JavaDoc , и будущие коммиттеры могут в любом случае просто удалить все это. Мне бы очень понравилось позитивное, но я беспокоюсь о негативном.
Итак: безопасно ли использовать Lombok в любом проекте, маленьком или большом? Стоят ли положительные эффекты отрицательных?
javac
, чтобы открыть доступ к внутреннимsun.*
классам ((Ответы:
Похоже, вы уже решили, что Project Lombok дает вам значительные технические преимущества для предложенного вами нового проекта. (Чтобы было ясно с самого начала, у меня нет особых взглядов на Project Lombok, так или иначе.)
Прежде чем использовать Project Lombok (или любую другую технологию, изменяющую игру) в каком-либо проекте (с открытым исходным кодом или иным способом), необходимо убедиться, что заинтересованные стороны проекта согласны с этим. Сюда входят разработчики и любые важные пользователи (например, официальные или неофициальные спонсоры).
Вы упоминаете эти потенциальные проблемы:
Легко. Игнорировать / не участвовать в флеймворах или просто не упоминать Ломбок.
Если стратегия проекта заключается в использовании Lombok, то возможные помощники должны будут привыкнуть к нему.
Это их проблема. Никто в здравом уме не пытается жестко применять правила исходного кода / документации своей организации к стороннему программному обеспечению с открытым исходным кодом. Команда проекта должна иметь возможность устанавливать стандарты исходного кода / документации проекта, соответствующие используемой технологии.
( FOLLOWUP - разработчики Lombok признают, что проблема заключается не в создании комментариев javadoc для синтезированных методов получения и установки. Если это является серьезной проблемой для вашего проекта (-ов), то одной из альтернатив является создание и отправка исправления Lombok для решения этой проблемы. )
Это не на! Если согласованная стратегия проекта заключается в использовании Lombok, то комментаторы, которые безвозмездно де-Ломбок кодируют, должны быть подвергнуты наказанию, и, если необходимо, их права на фиксацию отозваны.
Конечно, это предполагает, что у вас есть заинтересованные стороны ... включая разработчиков. И это предполагает, что вы готовы отстаивать свою причину и надлежащим образом обрабатывать неизбежные несогласные голоса.
источник
getCreationDate
,getDueDate
. Наименование превосходит комментарии, где это возможно.Просто начал использовать 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. Препятствия включают в себя: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
аннотацию и, возможно, добавляют обратно в аннотации, которые вы хотите.Насколько я могу судить, у 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:
Я не уверен, насколько я согласен с их оценкой. И учитывая минусы 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
!? Я не уверен, как происходит критическое изменение в обновлении "патча". Может быть проблема, если вы используете инструмент, который автоматически обновляет версии патча.источник
UPDATE 6
очень похоже на Scala :)Продолжайте и используйте Lombok, вы можете при необходимости «delombok» ваш код впоследствии http://projectlombok.org/features/delombok.html
источник
Лично (и, следовательно, субъективно) я обнаружил, что использование Lombok делает мой код более выразительным о том, чего я пытаюсь достичь, по сравнению с реализациями IDE / собственных сложных методов, таких как hashcode & equals.
Когда используешь
гораздо проще поддерживать Equals & HashCode и отслеживать, какие поля оцениваются, чем любую IDE / собственную реализацию. Это особенно верно, когда вы все еще регулярно добавляете / удаляете поля.
То же самое касается
@ToString
аннотации и ее параметров, которые четко сообщают о желаемом поведении относительно включенных / исключенных полей, использования геттеров или доступа к полям, а также о том, вызывать или не вызыватьsuper.toString()
.И снова, аннотируя целый класс с помощью
@Getter
или@Setter(AccessLevel.NONE)
(и, возможно, переопределяя любые расходящиеся методы), сразу становится ясно, какие методы будут доступны для полей.Преимущества продолжаются и продолжаются ..
На мой взгляд, речь идет не о сокращении кода, а о четком сообщении того, чего вы хотите достичь, а не о том, чтобы выяснить это с помощью Javadoc или реализаций. Сокращенный код облегчает обнаружение любых реализаций расходящихся методов.
источник
Ломбок отличный, но ...
Lombok нарушает правила обработки аннотаций тем, что не генерирует новые исходные файлы. Это означает, что он не может использоваться с другими процессорами аннотаций, если они ожидают, что получатели / установщики или что-то еще существует.
Обработка аннотации проходит в серии раундов. В каждом раунде каждый получает по очереди. Если какие-либо новые файлы Java будут найдены после завершения раунда, начинается новый раунд. Таким образом, порядок обработки аннотаций не имеет значения, если они генерируют только новые файлы. Поскольку lombok не генерирует никаких новых файлов, новые раунды не запускаются, поэтому некоторые точки доступа, основанные на коде lombok, не работают должным образом. Это было огромным источником боли для меня при использовании mapstruct, и delombok-ing не является полезным вариантом, поскольку он уничтожает ваши номера строк в журналах.
В конце концов я взломал скрипт сборки для работы с lombok и mapstruct. Но я хочу отбросить ломбок из-за того, насколько он хакерский - по крайней мере, в этом проекте. Я все время использую ломбок в других вещах.
источник
Я прочитал некоторые мнения о Ломбоке и фактически использую его в некоторых проектах.
Что ж, при первом контакте с Ломбоком у меня сложилось плохое впечатление. Через несколько недель мне это понравилось. Но через несколько месяцев я обнаружил множество мелких проблем с его использованием. Итак, моё последнее впечатление о Ломбоке не так положительно.
Мои причины думать так:
@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor
блок аннотаций, не задумываясь о том, какие методы классу действительно нужно предоставить.@Builder
вместо конструктора или статического конструктора метод. Иногда они даже пытаются создать Builder внутри Lombok Builder, создавая такие странные ситуации, какMyClass.builder().name("Name").build().create()
.@AllArgsConstructor
и вам нужно добавить еще один параметр в конструктор, IDE не может помочь вам добавить этот дополнительный параметр во всех местах (в основном, в тестах), в которых создается экземпляр класса.Как сказал другой ответ, если вы недовольны многословием Java и используете Lombok, попробуйте Kotlin.
источник
Есть и долгосрочные риски обслуживания. Во-первых, я бы рекомендовал прочитать о том, как на самом деле работает Lombok, например, некоторые ответы его разработчиков здесь .
Официальный сайт также содержит список недостатков , в том числе цитату из Reinier Zwitserloot:
Таким образом, в то время как 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:
@Getter
,@Setter
и т.д. аннотации). Вместо того, чтобы изучать альтернативный синтаксис для Java, я бы переключился на любой другой язык, который изначально предоставляет синтаксис Lombok.В общем, я бы не предпочел "оживить" мою 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
Обновить
Обновить
Я очень рекомендую перейти с 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 .
источник