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

Question

Я придумываю цели производительности на новый год, и я подумал, что мне будет интересно поставить цель, чтобы уменьшить размер базы кода, особенно шаблон. Одно из действий, которое я придумал для этого, - использовать Project Lombok, чтобы сделать бобы такими короткими, какими они должны быть. Но у меня есть привычка игнорировать недостатки нового программного обеспечения и подходов, поэтому я полагаюсь на сообщество переполнения стека: может ли кто-нибудь сказать мне, почему Ломбок - плохая идея?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Проект lombok добавляет байт-код для геттера/сеттера в файл класса на этапе компиляции.

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

Для выполнения фазы компиляции доступны несколько обходных решений. См. Это git hub ticket для более подробной информации.

Примечания: Я использую STS язь к весне и поддерживается Ломбками :)

Answer 5

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

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

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

Answer 6

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