Каковы риски с проектом Lombok?
Я придумываю цели производительности на новый год, и я подумал, что мне будет интересно поставить цель уменьшить размер базы кода, особенно шаблона. Одно из действий, которое я придумал для этого, - использовать Project Lombok, чтобы сделать beans настолько коротким, насколько это должно быть. Но у меня есть привычка игнорировать недостатки нового программного обеспечения и подходов, поэтому я полагаюсь на сообщество Stack Overflow: может ли кто-нибудь сказать мне, почему Ломбок - плохая идея?
Ответы
Ответ 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. Более того, я думаю, что аннотации не были предназначены для влияния на семантику языка.