Каковы риски с проектом Lombok?

Ответ 1

Основным недостатком является поддержка IDE. Поскольку Lombok на самом деле не является языковым изменением, и поскольку ваша среда IDE понимает только java, вам понадобится среда IDE, которая поддерживает Lombok, чтобы правильно работать. На данный момент это только Eclipse, который включает Eclipse и IntelliJ. Если вы используете eclipse, что может быть хорошо, но помните, что вы принимаете решение и для будущих разработчиков.

Я бы предложил вам переместить часть своего кода на менее церемониальный язык, например groovy. Мы успешно продвинули часть нашей бизнес-логики и моделей в groovy, и она работает очень плавно.

Ответ 2

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

Ответ 3

Одним из потенциальных недостатков чего-то вроде Ломбока является то, что с отсутствием сеттеров/геттеров исходные инструменты могут не "распознавать" аспекты результирующего объекта, которые придают ему качества "bean", поскольку эти качества проявляются только в скомпилированный класс.

Другим недостатком является то, что это еще одна часть "черной магии" внутри цепочки инструментов. К счастью, это кажется довольно мягкой штукой (я ее не использовал), и тот факт, что это происходит во время компиляции, а не во время выполнения, на самом деле является благословением (ИМХО). Но вы не сможете повторно использовать или делиться своим кодом без проекта, так как он добавляет артефакты к вашей базе кода. Поэтому, хотя скомпилированный файл класса может быть "POJO", я бы сказал, что ваш исходный код НЕ является POJO.

Ни один из них не искажает недостатки, а просто аспекты, которые нужно учитывать в ожидании.

Ответ 4

Как указано пользователем @Jcs в другом ответе, я хотел бы добавить еще.

В нашем проекте мы используем mapstruct, который используется для создания классов сопоставления, прежде чем компилировать код, используя команду mvn generate-sources, это делается на этапе процесса с использованием плагина процессора maven.

project lombok добавляет байт-код для getter/setter в файл класса на этапе компиляции.

поскольку фаза процесса выполняется перед компиляцией, она обнаруживает, что в классе нет доступных getter/setter.

Существует несколько обходных путей для выполнения этапа компиляции более одного. Подробнее см. git hub ticket.

Примечание. Я использую STS ide Spring и поддерживается lombok:)

Ответ 5

Это сторонняя библиотека, и есть разработчики, которые этого не знают.

IDE должна поддерживать обработку аннотаций (есть плагины для IDEA и Eclipse).

Как уже упоминалось выше, ваш код будет без getters/seters. Это приводит к нарушениям сонара/чека.

Ответ 6

По-моему, исходный код в "Java + Lombok" больше не является исходным кодом Java. Я вижу это как нечто подобное Borland, созданное много лет назад в своей Borland С++ Builder IDE для VCL - они представили "свойства" в коде на С++, эффективно внедряя какой-то новый язык программирования, который больше не был С++ (а не С++ в смысле стандарт языка С++). Источники, использующие "Java + Lombok", не являются достоверными источниками в смысле спецификации языка Java. Более того, я думаю, что аннотации не были предназначены для влияния на семантику языка.