Чи безпечно використовувати Project Lombok? [зачинено]

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

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

Отже: Чи безпечно використовувати Lombok у будь-якому проекті, малому чи великому? Чи варті позитивні ефекти негативні?

Здається, ви вже вирішили, що Project Lombok дає ваші технічні переваги для запропонованого нового проекту. (Щоб було зрозуміло з самого початку, я не маю особливих поглядів на Project Lombok, так чи інакше.)

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

Ви згадуєте про ці потенційні проблеми:

Полум'я вогнів спалахне в каналі ## Java Freenode, коли я згадую про нього,

Легко. Ігноруйте / не беруть участі у полум'ях або просто утримуйтесь від згадки про Ломбок.

надання фрагментів коду може заплутати можливих помічників,

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

люди скаржаться на відсутність JavaDoc,

У цьому їхня проблема. Ніхто з розуму не намагається жорстко застосовувати вихідні коди / правила документації своєї організації до сторонніх програм із відкритим кодом. Команда проекту повинна вільно встановлювати вихідні коди / стандарти документації проекту, які відповідають технології, що використовується.

( FOLLOWUP - Розробники Lombok визнають, що не генерувати коментарі javadoc для синтезованих методів геттера та сеттера є проблемою. Якщо це основна проблема для ваших проектів, тоді одна з альтернатив - створити та подати патч Lombok для вирішення цього питання. )

а майбутні уповноважені можуть все-таки видалити все це.

Це не на! Якщо узгоджена стратегія проекту полягає у використанні Lombok, тоді комітети, які безоплатно де-Ломбок, повинні піддавати кримінальній відповідальності, а за потреби відкликати свої права на зобов'язання.

Звичайно, це передбачає, що ви купуєте акції від зацікавлених сторін ... включаючи розробників. І передбачається, що ви готові аргументувати свою справу і належним чином поводитися з неминучими голосами суперечок.

Щойно почав використовувати Lombok сьогодні. Поки мені це подобається, але один недолік, якого я не бачив, це підтримка рефакторингу.

Якщо у вас є анотація класу @Data, він генерує для вас getters та setters на основі назв полів. Якщо ви використовуєте один з цих гетерів в іншому класі, то вирішите, що поле названо погано, воно не знайде звичаї цих геттерів та сеттерів та замінить стару назву новою назвою.

Я думаю, що це потрібно робити через плагін IDE, а не через Lombok.

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

Якщо у вас є клас, скажіть, MyCompoundObject.javaщо у нього є 2 члени, на яких позначено повідомлення @Delegate, скажімо, myWidgetsі myGadgets, коли ви телефонуєте myCompoundObject.getThingies()з іншого класу, неможливо дізнатися, чи він делегується до Widgetабо Gadgetтому, що ви більше не можете переходити до джерела в IDE.

Використання Eclipse "Створення методів делегації ..." надає вам таку ж функціональність, так само швидко і забезпечує стрибки з джерела. Мінус полягає в тому, що він захаращує ваш джерело кодовою табличкою, яка знімає фокус важливих речей.

ОНОВЛЕННЯ 2 (26 лютого 1313 р.)
Через 5 місяців ми все ще використовуємо Ломбок, але у мене є деякі інші прикрості. Відсутність заявленого геттера та сеттера може набриднути, коли ви намагаєтесь ознайомитись з новим кодом.

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

• Відсутність JavaDocs. Якби я поширював поле, я сподіваюся, що геттер і сетер успадкують цей Javaдок через крок компіляції Ломбока.
• Перейти до визначення методу переходить мене до класу, але не до властивості, яка генерувала гетьтер. Це проблема із плагінами.
• Очевидно, ви не в змозі встановити точку розриву в геттере / сеттері, якщо не створити або кодувати метод.
• ПРИМІТКА. Цей довідковий пошук не є проблемою, як я вперше вважав, що це. Вам потрібно використовувати перспективу, яка дозволяє переглядати контур. Не є проблемою для більшості розробників. Моя проблема полягала в тому, що я використовую Mylyn, яка фільтрувала мій Outlineпогляд, тому я не бачив методів. Відсутність пошуку літератури. Якщо я хочу побачити, хто дзвонить getDynamicCols(args...), мені доведеться генерувати або кодувати сеттер, щоб мати змогу шукати посилання.

ОНОВЛЕННЯ 3 (7 березня 1313 р.)
Навчаюсь використовувати різні способи ведення справ у Eclipse. Ви можете фактично встановити умовну точку розриву (ВР) методом, створеним у Ломбоку. ВикористанняOutline представлення даних, ви можете клацнути правою кнопкою миші метод до Toggle Method Breakpoint. Потім, натиснувши ВР, ви можете скористатися Variablesподанням налагодження, щоб побачити, який згенерований метод назвав параметри (як правило, такі самі, як назва поля) і, нарешті, скористатися Breakpointsподанням, щоб клацнути правою кнопкою миші ВР та вибрати, Breakpoint Properties...щоб додати умову. Приємно.

ОНОВЛЕННЯ 4 (16 серпня 1313)
Netbeans не сподобається, коли ви оновлюєте свої залежності від Lombok у своєму 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примітка переведена на статус експерименту. Деталі задокументовані на їхньому сайті ( Документи Lombok Delegate ).

Вся справа в тому, що якщо ви використовували цю функцію, ваші варіанти резервного копіювання обмежені. Я бачу варіанти як:

• Видаліть вручну @Delegate примітки та генеруйте / передайте вручну код делегатного коду. Це трохи складніше, якщо ви використовували атрибути в примітці.
• Розгорніть файли, які містять @Delegateпримітку, і, можливо, додайте їх до потрібних приміток.
• Ніколи не оновлюйте Lombok і не підтримуйте розвилку (або в прямому ефірі з використанням досвідчених функцій).
• Делобок весь ваш проект і припиніть використовувати 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 як можливе рішення проблеми, яку вони намагаються вирішити. Мінуси, які вони перераховують для Ломбока:

• Вставний код невидимий (ви не можете "бачити" методів, які він генерує) [ed примітка - насправді ви можете, але для цього просто потрібен декомпілятор]
• Хаки для компілятора нестандартні та крихкі
• "На наш погляд, ваш код уже не справді Java"

Я не впевнений, наскільки я згоден з їх оцінкою. І з огляду на мінуси AutoValue, які зафіксовані на слайдах, я буду дотримуватися Lombok (якщо Groovy не є варіантом).

ОНОВЛЕННЯ 11 (8 лютого 1616 р.)
Я дізнався, що Spring Roo має кілька подібних приміток . Я трохи здивувався, дізнавшись, що Роо все ще є річчю, і пошук документації для анотацій є дещо грубою. Видалення також виглядає не так просто, як de-lombok. Ломбок здається більш безпечним вибором.

ОНОВЛЕННЯ 12 (17 лютого 1616 р.)
Під час спроби придумати виправдання, чому можна безпечно привезти в Ломбок проект, над яким я зараз працюю, я знайшов золоту частину, яку додали v1.14- Конфігураційна система ! Це означає, що ви можете налаштувати проект так, щоб заборонити певні функції, які ваша команда вважає небезпечними або небажаними. Що ще краще, він також може створити конфігурацію конкретного каталогу, що має різні налаштування. Це круто.

ОНОВЛЕННЯ 13 (4 жовтня 1616 р.)
Якщо подібні речі для вас важливі, Олівер Дьерке вважав, що безпечно додати Ломбок до весняного відпочинку .

ОНОВЛЕННЯ 14 (26 вересня 1717 р.)
Як вказувало @gavenkoa в коментарях до питання про оперативні програми, підтримка компілятора JDK9 ще не доступна (випуск № 985). Це також звучить так, що команда Ломбок не зможе легко виправити цю проблему.

ОНОВЛЕННЯ 15 (26 березня 18 р.)
Блог змін у Lombok вказує станом на v1.16.20 " Компіляція lombok на JDK1.9 тепер можлива ", хоча # 985 все ще відкритий.

Однак зміни, що стосуються розміщення JDK9, потребували певних змін; всі ізольовані для зміни параметрів конфігурації. Це трохи стосується того, що вони внесли неполадки в зміни, але версія лише зіткнулася з "Поступовим" номером версії (від v1.16.18 до v1.16.20). Оскільки ця публікація стосувалася безпеки, якщо у вас була система yarn/npmсхожої збірки, яка автоматично оновилася до останньої інкрементальної версії, можливо, ви будете за грубе пробудження.

ОНОВЛЕННЯ 16 (9 січня 1919)

Здається, проблеми з JDK9 були вирішені, і Lombok працює з JDK10, і навіть JDK11, наскільки я можу сказати.

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

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

Особисто (і тому суб'єктивно) я виявив, що використання Lombok робить мій код більш виразним щодо того, чого я намагаюся досягти порівняно з IDE / власними реалізаціями складних методів, таких як хеш-код і рівняння.

При використанні

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

набагато простіше тримати послідовність рівня рівних та HashCode і слідкувати за тим, які поля оцінюються, ніж будь-яка IDE / власна реалізація. Це особливо актуально, коли ви все ще регулярно додаєте / видаляєте поля.

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

І знову шляхом анотування цілого класу з @Getterабо@Setter(AccessLevel.NONE) (і , можливо , відкидаючи будь-які методи розходяться) це відразу зрозуміло , які методи будуть доступні для полів.

Переваги продовжують і далі ..

На мій погляд, справа не в зменшенні коду, а в чіткому повідомленні того, чого ви хочете досягти, а не в тому, щоб зрозуміти це з Javadoc або реалізації. Знижений код просто полегшує виявлення будь-яких реалізацій розбіжних методів.

Ломбок чудовий, але ...

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

Обробка анотацій працює в серії раундів. У кожному раунді кожен отримує свою чергу на біг. Якщо будь-які нові файли java знайдені після завершення раунду, починається ще один раунд. Таким чином, порядок процесорів анотацій не має значення, якщо вони генерують лише нові файли. Оскільки lombok не генерує жодних нових файлів, не запускаються нові раунди, тому деяка AP, яка спирається на код lombok, не працює так, як очікувалося. Це було величезним джерелом болю для мене під час використання mapstruct, і delombok-ing не є корисним варіантом, оскільки він руйнує ваші номери рядків у журналах.

Зрештою, я зламав сценарій збірки для роботи з lombok і mapstruct. Але я хочу скинути lombok через те, наскільки він гакітний - принаймні в цьому проекті. Я весь час використовую lombok в інших речах.

Я читав деякі думки про Ломбок і фактично використовую його в деяких проектах.

Що ж, у першому контакті з Ломбоком у мене було погане враження. Через кілька тижнів мені це почало подобатися. Але через кілька місяців я з’ясовую безліч крихітних проблем з його використанням. Отже, моє остаточне враження про Ломбок не таке позитивне.

Мої причини мислити так:

• IDE плагін залежностей . Підтримка IDE для Lombok здійснюється через плагіни. Навіть працюючи добре протягом більшої частини часу, ви завжди є заручником цих плагінів, які потрібно підтримувати в майбутніх випусках IDE і навіть мовної версії (Java 10+ прискорить розвиток мови). Наприклад, я спробував оновити з Intellij IDEA 2017.3 до 2018.1, і я не міг цього зробити, оскільки в дійсній версії плагіна lombok виникла якась проблема, і мені потрібно було почекати оновлення плагіна ... Це також проблема, якщо ви хотіли б використовувати більш альтернативну IDE, яка не підтримує плагін Lombok.
• Проблема "Знайти звички". . Використовуючи Lombok, ви не бачите створених методів getter, setter, конструктора, builder тощо. Отже, якщо ви плануєте дізнатися, де ці методи використовуються у вашому проекті вашим IDE, ви не можете це зробити лише шукаючи для класу, якому належать ці приховані методи.
• Настільки легко, що розробники не переймаються інкапсуляцією . Я знаю, що насправді це не проблема від Ломбока. Але я побачив більшу тенденцію від розробників більше не контролювати, які методи мають бути видимими чи ні. Отже, багато разів вони просто копіюють і вставляють @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorблок анотацій, не замислюючись над тим, які методи класу дійсно потрібно піддавати впливу.
• Нерухомість будівельника ©. Я вигадав це ім’я (геть, Мартін Фаулер). Жартуючи окремо, Builder так легко створити, що навіть коли у класу є лише два параметри, розробники вважають за краще використовувати @Builderзамість конструктора або статичний метод конструктора. Іноді вони навіть намагаються створити Builder всередині ломбока Builder, створюючи дивні ситуації на кшталт MyClass.builder().name("Name").build().create().
• Бар'єри при рефакторингу . Якщо ви використовуєте, наприклад, a @AllArgsConstructorі вам потрібно додати ще один параметр на конструкторі, IDE не може допомогти вам додати цей додатковий параметр у всіх місцях (в основному, тестів), які інстанціюють клас.
• Змішування Ломбока конкретними методами . Ви не можете використовувати Lombok у всіх сценаріях для створення геттера / сетера / тощо. Отже, ви побачите ці два підходи, змішані у вашому коді. Ти звикаєш до цього через деякий час, але відчуваєш, як зламати мову.

Як сказано в іншій відповіді, якщо ви злилися на багатослівність Java і використовуєте Lombok для боротьби з цим, спробуйте Котлін.

Існують також ризики тривалого обслуговування. По-перше, я рекомендую прочитати про те, як Lombok насправді працює, наприклад, деякі відповіді від його розробників тут .

Офіційний сайт також містить перелік недоліків , включаючи цю цитату від Реньє Цвіцерлоот:

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

У затемненні це, мабуть, гірше (та ще більш надійно) - агент java використовується для введення коду до класу граматики та парсера eclipse, що, звичайно, є повністю непублічним API та зовсім поза межами.

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

Як підсумок, хоча Lombok може заощадити певний час на розробку, якщо існує оновлене оновлення javac, яке не підтримується назад (наприклад, пом’якшення вразливості) внутрішні API. Чи це серйозний ризик, очевидно, залежить від проекту.

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

Що стосується вашого питання: напевно простіше змусити своїх розробників спробувати Lombok, ніж Scala. Спробуйте, і якщо їм це подобається, спробуйте Scala.

Як відмова від відповідальності: мені подобається і Java!

Я використовував Ломбок майже у всіх своїх проектах протягом одного року, але, на жаль, його видалив. На початку це був дуже чистий шлях розвитку, але створити середовище розробки для нових членів команди не дуже просто та просто. Коли це стало головним болем, я просто зняв його. Але це хороша робота і потребує трохи більшої простоти для налаштування.

Коли я показав проект своїй команді, ентузіазм був високим, тому я думаю, що ви не повинні боятися реакції команди.

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

• І останнє, якщо ви передумаєте, можете запустити unlombok або дозволити вашій IDE створити ці сетери, геттери та цитри, (які, я думаю, ніхто не запитає, як тільки вони побачать, наскільки ясним стає ваше pojo)

Я вважаю, що він пропонує лише ярлики для написання Java-коду.
Що стосується використання ярликів для написання Java-коду bolilerplate, я б покладався на такі функції, які надає IDE - наприклад, у Eclipse, ми можемо перейти до меню Source> Generate Getters and Setters для генерації геттерів та сетерів.
Я б не покладався на таку бібліотеку, як Ломбок:

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

Взагалі я б не вважав за краще "приправляти" мою Java Ломбоком.

Хотіли використати ломбок, @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.

Довелося вручну копіювати згенеровані методи з джерела деломбокованої роботи та перевести lombok у режим очікування до кращих часів.

Оновлення

Проблема виникає лише при включенні паралельної компіляції.

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

Оновлення

mplushnikov прокоментував 30 січня 2016 року:

Новіша версія Intellij вже не має таких проблем. Я думаю, що тут можна закрити.

Оновлення

Я б дуже рекомендував, якщо можливо, перейти з Java + Lombok до Kotlin . Як це вирішило з самого початку всі проблеми з Java, які намагається вирішити Ломбок.

У мене виникли проблеми з CSV Lombok та Jackson , коли я марширував свій об’єкт (java bean) у файл CSV, стовпці де дублювались, тоді я видалив анотацію @Data Lombok і маршалізація спрацювала нормально.

Я не рекомендую. Раніше я його використовував, але тоді, коли я працюю з NetBeans 7.4, він зіпсував мої коди. Я маю видалити lombok з усіх файлів у своїх проектах. Деломбок є, але як я можу бути впевнений, що він не накрутить мої коди. Мені доводиться витрачати дні, щоб видалити ломбок і повернутися до звичайних стилів Java. Я просто занадто гострий ...

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