Не работают аннотации lombok

Ломбокские аннотации не компилируются по идее Intellij

Кажется, все в порядке. Но когда я компилирую тест, появляются ошибки: не могу найти методы getXXX и setXXX.

Я открыл файл .class с IntelliJ и обнаружил, что методов setXXX и getXXX не существует.

Может кто-нибудь сказать мне, почему?

• плагин: lombok-plugin-0.8.6-13
• lombok.jar: 1.14.0
• идея: 13.0.2 для Linux
• JDK: 1.7.0_21

11 ответов

Для решения проблемы установите:

• Настройки (Ctrl + Alt + S)
  • Сборка, выполнение, развертывание
    • Compiler
      • Процессоры аннотаций
        • Включить обработку аннотаций

Убедитесь, что у вас установлен плагин Lombok для IntelliJ!

• Настройки -> Плагины
• Поиск «Плагин Lombok»
• Нажмите Обзор репозиториев .
• Выберите плагин Lombok
• Установить
• Перезапустите IntelliJ

Если вы используете компилятор Eclipse с lombok, эта настройка наконец-то сработала для меня:

• ИДЕЯ 14.1
• Плагин Lombok
• . / Компилятор / Java Compiler > Использовать компилятор: Eclipse
• . / Компилятор / Процессоры аннотаций > Включить обработку аннотаций: отмечен (конфигурация по умолчанию)
• . / Компилятор > Дополнительные параметры виртуальной машины процесса сборки: -javaagent: lombok.jar

Самая важная часть — последняя, ​​моя выглядит следующим образом:

Плагин необходим для того, чтобы редактор IntelliJ мог распознавать методы получения и установки, javaagent необходим для компиляции eclipse с помощью lombok.

Для меня нужен как плагин lombok, так и обработка аннотаций, больше ничего. Нет необходимости использовать Eclipse и дополнительные параметры -javaagent: lombok.jar .

• Идея 14.1.3, сборка 141.1010
• Плагин Lombok [Preference-> plugins-> browse repositories-> search ‘lombok’ -> идея установки и перезапуска.
• Предпочтение -> поиск ‘annotation’ -> введите процессор аннотаций -> включить обработку аннотаций.

ИДЕЯ 2016.1:

• Установите плагин lombok
• Настройки -> Компилятор -> Процессоры аннотаций -> Включить обработку аннотаций: проверено (конфигурация по умолчанию)
• Настройки -> Компилятор -> Процессоры аннотаций -> Процессоры аннотации добавляют «lombok.launch.AnnotationProcessorHider $ AnnotationProcessor»

Также, если вы используете maven, добавьте в конфигурацию maven-compiler-plugin -> annotationProcessors -> annotationProcessor: lombok.launch.AnnotationProcessorHider $ AnnotationProcessor

Убедитесь, что эти два требования соблюдены.

Включить обработку аннотаций,

Настройки> Сборка, выполнение, развертывание> Компилятор> Процессоры аннотаций> Включить обработку аннотаций

Плагин Lombok установлен и включен для вашего проекта.

Потратив слишком много времени на устранение неполадок, я нашел простой обходной путь, который гарантирует, что IntelliJ правильно обрабатывает аннотации Lombok во время сборок.

Плагин Gradle-Lombok не требуется для этого обходного пути. Для вашего build.gradle требуется только следующее:

Обходной путь должен включить следующую настройку IntelliJ:

1. Откройте настройки /настройки IntelliJ.
2. Перейдите к Build, Execute, Deployment > Build Tools > Gradle > Runner
3. Установите флажок Delegate IDE build/run actions to gradle

Преимущества этого обходного пути по сравнению с другими решениями на этой странице:

• Обработка аннотаций не требуется!
• Возможность использовать компилятор Java по вашему выбору (компилятор Eclipse не требуется)
• Не использовать глючный плагин gradle-lombok (хотя, возможно, это решит кто-то другой)
• Не нужно указывать параметры виртуальной машины
• Нет жестко заданных путей к банке с ломбоком

Недостатком является то, что IntelliJ больше не будет использовать свой собственный бегун. Вместо этого тесты всегда выполняются через Gradle.

Ни один из расширенных ответов на этот вопрос не решил проблему для меня.

Мне удалось решить эту проблему, добавив зависимость к lombok в файле pom.xml, т.е.

Я использую IntelliJ 2016.3.14 с maven-3.3.9

Надеюсь, мой ответ будет вам полезен

Если вы используете Intellij на Mac, эта настройка наконец-то сработала для меня.

Установки: Intellij

1. Перейдите в настройки, найдите плагины.
2. Введите «Lombok» в поле поиска плагина. Lombok — это не связанный плагин, поэтому сначала он не будет отображаться.
3. Нажмите «Обзор», чтобы выполнить поиск не связанных плагинов
4. Должен появиться «Плагин Lombok». Выберите это.
5. Нажмите зеленую кнопку «Установить».
6. Нажмите кнопку «Перезапустить Intellij IDEA».

Настройки:

Включить процессор аннотаций

• Перейдите в настройки -> Сборка, выполнение, развертывание -> Настройки -> Компилятор -> Процессоры аннотаций
• Файл -> Другие настройки -> Настройки по умолчанию -> Компилятор -> Процессоры аннотаций

Проверьте, включен ли плагин Lombok

• IntelliJ IDEA-> Настройки -> Другие настройки -> Плагин Lombok -> Включить Ломбок

Добавьте Jom Lombok в глобальные библиотеки и зависимости проекта.

• Файл -> Структура проекта -> Глобальные библиотеки (Добавить lombok.jar)

Файл -> Структура проекта -> Настройки проекта -> Модули -> Вкладка «Зависимости» = проверка lombok

В Itellij 15 CE достаточно просто установить плагин Lombok (дополнительная настройка не требуется).

Я следовал этой процедуре, чтобы получить похожую /ту же ошибку.

Идея mvn: чистота

После этого я мог строить как из intellij среды IDE, так и из командной строки.

Я не могу заставить это работать с компилятором javac, и я получаю ту же ошибку.

Ошибка: (9, 14) java: пакет lombok не существует

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

Однако я заставил его частично работать с компилятором eclipse. Я говорю частично, потому что, хотя сборка проходит успешно, редактор все еще жалуется на «Невозможно разрешить символ».

Источник

Lombok + JPA: Что может пойти не так?

Lombok — это отличный инструмент, с которым Java-код становится чище и лаконичнее. Однако есть несколько нюансов, которые надо учитывать при его использовании с JPA. В этой статье мы выясним, как неправильное применение Lombok может повлиять на производительность приложений или даже привести к ошибкам. Разберемся, как этого избежать не теряя преимуществ Lombok.

Мы разрабатываем JPA Buddy — плагин для IntelliJ IDEA, который упрощает работу с JPA. Прежде чем приступить к разработке, мы проанализировали сотни проектов на GitHub, чтобы понять, как именно программисты взаимодействуют с JPA. Оказалось, что многие из них используют Lombok.

Использовать Lombok в проектах с JPA вполне можно, но нужно учитывать его некоторые особенности. Анализируя проекты, мы увидели, что разработчики снова и снова наступают на те же грабли. Именно поэтому мы добавили в JPA Buddy целый ряд инспекций кода для Lombok. Давайте рассмотрим наиболее распространенные проблемы, с которыми вы можете столкнуться при использовании Lombok с JPA.

Некорректно работающий HashSet (и HashMap)

Анализируя проекты, мы часто видели сущности, помеченные @EqualsAndHashCode или @Data. В документации по аннотации @EqualsAndHashCode сказано следующее:

По умолчанию реализации методов будут использовать все нестатические и не транзиентные поля. Однако вы можете явно указать используемые поля, пометив их с помощью аннотаций @EqualsAndHashCode.Include или @EqualsAndHashCode.Exclude .

Как правильно реализовать equals() / hashCode() для JPA-сущностей — вопрос не тривиальный. Сущности мутабельны по своей природе. Даже ID зачастую генерируется базой данных, то есть изменяется после первого сохранения сущности. Получается, не существует полей, на основе которых можно было бы консистентно вычислить hashCode.

Докажем это на практике. Создадим тестовую сущность:

И выполним следующий код:

Assert в последней строчке упадет с ошибкой, хотя сущность добавлена в set всего несколькими строками выше. Если использовать Delombok на этой сущности, мы увидим, что @EqualsAndHashCode под капотом реализует следующий код:

При первом сохранении сущности ID изменяется. Соответственно, меняется и hashCode. Именно поэтому HashSet и не может найти объект, который мы только что создали, так как он ищет его в другом бакете. Проблем бы не было, если бы ID был установлен во время создания объекта сущности (например, в качестве ID использовался бы UUID, генерируемый приложением), но чаще всего за генерацию идентификаторов отвечает именно база данных.

Непреднамеренная загрузка lazy полей

Как было отмечено выше, @EqualsAndHashCode по умолчанию использует все поля сущности. Такой же подход используется и для @ToString :

Любой класс может быть помечен аннотацией @ToString , чтобы Lombok сгенерировал реализацию метода toString() . По умолчанию сгенерированный метод toString() возвращает строку, содержащую имя класса и значения всех полей через запятую.

Получается, эти методы вызывают equals() / hashCode() / toString() на каждом поле сущности, включая lazy поля. Это может привести к их непреднамеренной загрузке.

Например, вызов hashCode() на lazy ассоциации @OneToMany может спровоцировать подгрузку всех связанных сущностей. Это может серьезно сказаться на производительности приложения или вызвать LazyInitializationException , если вызов произойдет вне транзакции.

Мы считаем, что вообще не стоит использовать @EqualsAndHashCode и @Data на сущностях, в JPA Buddy есть для этого инспекция:

Аннотацию @ToString можно использовать, если исключить все lazy поля. Для этого надо пометить lazy поля аннотацией @ToString.Exclude или использовать @ToString(onlyExplicitlyIncluded=true) на классе и @ToString.Include на не-lazy полях. В JPA Buddy есть для этого квик-фикс:

Конструктор без аргументов

Согласно спецификации JPA, все сущности должны иметь public или protected конструктор без аргументов. Очевидно, что при использовании @AllArgsConstructor компилятор не генерирует конструктор по умолчанию, это также касается и @Builder :

Применение @Builder к целому классу равноценно применению @AllArgsConstructor (access = AccessLevel.PACKAGE) на классе и @Builder на конструкторе с параметрами.

Поэтому обязательно используйте их с аннотацией @NoArgsConstructor или с конструктором без параметров:

Заключение

С Lombok ваш код выглядит чище, но, как и в случае с любым другим магическим инструментом, важно понимать, как именно он работает и когда его использовать. В противном случае производительность вашего приложения может снизиться, либо оно вовсе может перестать работать корректно. Как вариант, можно положиться на инструменты разработки, которые будут предупреждать вас о потенциальных проблемах.

При работе с JPA и Lombok помните следующие правила:

Избегайте использования аннотаций @EqualsAndHashCode и @Data с JPA сущностями;

Исключайте ленивые поля при использовании аннотации @ToString;

Не забывайте добавлять аннотацию @NoArgsConstructor к сущностям помеченным аннотациями @Builder или @AllArgsConstructor .

Есть еще один вариант: переложите ответственность за соблюдение этих правил на JPA Buddy, его инспекции кода всегда к вашим услугам.

Источник

Lombok возвращает величие Java

Мы в Grubhub почти во всём бэкенде используем Java. Это проверенный язык, который за последние 20 лет доказал свою скорость и надёжность. Но с годами возраст «старичка» всё-таки начал сказываться.

Java — один из самых популярных языков JVM, но не единственный. В последние годы конкуренцию ему составляют Scala, Clojure и Kotlin, которые обеспечивают новую функциональность и оптимизированные функции языка. Короче говоря, они позволяют делать больше с более лаконичным кодом.

Эти инновации в экосистеме JVM очень интересные. Из-за конкуренции Java вынуждена меняться, чтобы сохранить конкурентоспособность. Новый шестимесячный график выпуска и несколько JEP (JDK enhancement proposals) в Java 8 (Valhalla, local-Variable Type Inference, Loom) — доказательство того, что Java долгие годы останется конкурентоспособным языком.

Тем не менее, размер и масштаб Java означают, что разработка продвигается медленнее, чем мы хотели бы, не говоря уже о сильном желании любой ценой поддерживать обратную совместимость. В любой разработке первым приоритетом должны быть функции, однако здесь необходимые функции слишком долго разрабатываются, если вообще попадают в язык. Поэтому мы в Grubhub используем Project Lombok, чтобы прямо сейчас иметь в своём распоряжении оптимизированную и улучшенную Java. Проект Lombok — это плагин компилятора, который добавляет в Java новые «ключевые слова» и превращает аннотации в Java-код, уменьшая усилия на разработку и обеспечивая некоторую дополнительную функциональность.

Настройка Lombok

Grubhub всегда стремится улучшить жизненный цикл программного обеспечения, но каждый новый инструмент и процесс имеет стоимость, которую следует учесть. К счастью, для подключения Lombok достаточно добавить всего пару строк в файл gradle.

Lombok преобразует аннотации в исходном коде в Java-операторы до того, как компилятор их обработает: зависимость lombok отсутствует в рантайме, поэтому использование плагина не увеличит размер сборки. Чтобы настроить Lombok с Gradle (он также работает с Maven), просто добавьте в файл build.gradle такие строки:

При использовании Lombok наш исходный код не будет валидным кодом Java. Поэтому потребуется установить плагин для IDE, иначе среда разработки не поймёт, с чем имеет дело. Lombok поддерживает все основные Java IDE. Интеграция бесшовная. Все функции вроде «показать использования» и «перейти к реализации» продолжают работать как и раньше, перемещая вас к соответствующему полю/классу.

Lombok в действии

Лучший способ познакомиться с Lombok — увидеть его в действии. Рассмотрим несколько типичных примеров.

Оживить объект POJO

При помощи «старых добрых объектов Java» (POJO) мы отделяем данные от обработки, чтобы сделать код проще для чтения и упростить сетевые передачи. В простом POJO есть несколько приватных полей, а также соответствующие геттеры и сеттеры. Они справляются с работой, но требуют большого количества шаблонного кода.

Lombok помогает использовать POJO более гибким и структурированным образом без дополнительного кода. Вот так с помощью аннотации @Data мы упрощаем базовый POJO:

@Data — просто удобная аннотация, которая применяет сразу несколько аннотаций Lombok.

• @ToString генерирует реализацию для метода toString() , которая состоит из аккуратного представления объекта: имя класса, все поля и их значения.
• @EqualsAndHashCode генерирует реализации equals и hashCode , которые по умолчанию используют нестатические и нестационарные поля, но настраиваются.
• @Getter / @Setter генерирует геттеры и сеттеры для частных полей.
• @RequiredArgsConstructor создаёт конструктор с требуемыми аргументами, где обязательными являются окончательные поля и поля с аннотацией @NonNull (подробнее об этом ниже).

Одна эта аннотация просто и элегантно охватывает многие типичные случаи использования. Но POJO не всегда покрывает необходимую функциональность. @Data — полностью изменяемый класс, злоупотребление которым может повысить сложность и ограничить параллелизм, что негативно отражается на живучести приложения.

Есть другое решение. Вернёмся к нашему классу User , сделаем его неизменяемым и добавим несколько других полезных аннотаций.

Аннотация @Value аналогична @Data за исключением того, что все поля по умолчанию являются закрытыми и окончательными, а сеттеры не создаются. Благодаря этому объекты @Value сразу становятся неизменяемыми. Поскольку все поля являются окончательными, конструктора аргументов нет. Вместо этого Lombok использует @AllArgsConstructor . В результате получается полностью функциональный, неизменяемый объект.

Но неизменяемость не очень полезна, если вам нужно всего лишь создать объект с помощью конструктора all-args. Как объясняет Джошуа Блох в книге «Эффективное программирование на Java», при наличии большого количества параметров конструктора следует использовать билдеры. Тут вступает в действие класс @Builder , автоматически генерируя внутренний класс билдера:

Генерация билдера упрощает создание объектов с большим количеством аргументов и добавлением новых полей в будущем. Статический метод возвращает экземпляр билдера для задания всех свойств объекта. После этого вызов build() возвращает инстанс.

Аннотацию @NonNull можно использовать для утверждения, что эти поля не являются нулевыми при создании экземпляра объекта, иначе выбрасывается исключение NullPointerException . Обратите внимание, что поле аватара аннотировано @NonNull , но не задано. Дело в том, что аннотация @Builder.Default по умолчанию указывает на default.png.

Также обратите внимание, как билдер использует favoriteFood , единственное название свойства в нашем объекте. При размещении аннотации @Singular на свойстве коллекции Lombok создаёт специальные методы билдера для индивидуального добавления элементов в коллекцию, а не для одновременного добавления всей коллекции. Это особенно хорошо для тестов, потому что способы создания маленьких коллекций в Java нельзя назвать простыми и быстрыми.

Наконец, параметр toBuilder = true добавляет метод экземпляра toBuilder() , который создаёт объект билдера, заполненный всеми значениями этого экземпляра. Так легко создаётся новый инстанс, предварительно заполненный всеми значениями из исходного, так что остаётся изменить лишь необходимые поля. Это особенно полезно для классов @Value , поскольку поля неизменяемы.

Несколько примечаний дополнительно настраивают специальные функции сеттера. @Wither создаёт методы withX для каждого свойства. На входе — значение, на выходе — клон экземпляра с обновлённым значением одного поля. @Accessors позволяет настраивать автоматически созданные сеттеры. Параметр fluent=true отключает конвенцию “get” и “set” для геттеров и сеттеров. В определённых ситуациях это может быть полезной заменой @Builder .

Если реализация Lombok не подходит для вашей задачи (и вы посмотрели на модификаторы аннотаций), то всегда можно просто взять и написать собственную реализацию. Например, если у вас класс @Data , но один геттер нуждается в пользовательской логике, просто реализуйте этот геттер. Lombok увидит, что реализация уже предоставлена, и не перезапишет её автоматически созданной реализацией.

С помощью всего нескольких простых аннотаций базовый POJO получил так много богатых функций, которые упрощают его использование, не загружая работой нас, инженеров, не отнимая время и не увеличивая затраты на разработку.

Удаление шаблонного кода

Lombok полезен не только для POJO: его можно применить на любом уровне приложения. Следующие способы использования Lombok особенно полезны в классах компонентов, таких как контроллеры, службы и DAO (объекты доступа к данным).

Ведение журнала — базовое требование для всех частей программы. Любой класс, выполняющий значимую работу, должен записывать лог. Таким образом, стандартный логгер становится шаблоном для каждого класса. Lombok упрощает этот шаблон до одной аннотации, которая автоматически определяет и создаёт экземпляр логгера с правильным именем класса. Существует несколько различных аннотаций в зависимости от структуры журнала.

После объявления логгера добавляем наши зависимости:

Аннотация @FieldDefaults добавляет ко всем полям окончательный и приватный модификаторы. @RequiredArgsConstructor создаёт конструктор, который устанавливает экземпляр UserDao . Аннотация @NonNull добавляет проверку в конструкторе и создаёт исключение NullPointerException , если экземпляр UserDao равен нулю.

Но подождите, это ещё не всё!

Есть ещё много ситуаций, где Lombok проявляет себя с лучшей стороны. Предыдущие разделы показывали конкретные примеры, но Lombok может облегчить разработку во многих областях. Вот несколько небольших примеров, как эффективнее его использовать.

Хотя в Java 9 появилось ключевое слово var , но переменную всё равно можно переназначить. В Lombok есть ключевое слово val , которое выводит окончательный тип локальной переменной.

Некоторые классы c чисто статическими функциями не предназначены для инициализации. Один из способов предотвратить создание экземпляра — объявить приватный конструктор, который выбрасывает исключение. Lombok кодифицировал этот шаблон в аннотации @UtilityClass . Она генерирует приватный конструктор, который создаёт исключение, окончательно выводит класс и делает все методы статическими.

Java часто критикуют за многословность из-за проверяемых исключений. Отдельная аннотация Lombok устраняет их: @SneakyThrows . Как и следовало ожидать, реализация довольно хитрая. Она не перехватывает исключения и даже не оборачивает исключения в RuntimeException . Вместо этого она полагается на тот факт, что во время выполнения JVM не проверяет согласованность проверяемых исключений. Так делает только javac. Поэтому Lombok с помощью преобразования байт-кода во время компиляции отключает эту проверку. В результате получается запускаемый код.

Сравнение бок о бок

Прямое сравнение лучше всего демонстрирует, сколько кода экономит Lombok. В плагине IDE есть функция “de-lombok”, которая приблизительно преобразует большинство аннотаций Lombok в нативный Java-код (аннотации @NonNull не конвертируются). Таким образом, любая IDE с установленным плагином сможет конвертировать большинство аннотаций в собственный код Java и обратно. Вернёмся к нашему классу User .

Класс Lombok — всего лишь 13 простых, читаемых, понятных строк. Но после запуска de-lombok, класс превращается более чем в сто строк шаблонного кода!

То же самое сделаем для класса UserService .

Вот примерный аналог в стандартном Java-коде.

Оценка эффекта

На портале Grubhub более ста бизнес-сервисов, связанных с доставкой еды. Мы взяли один из них и запустили функцию “de-lombok” в плагине Lombok IntelliJ. В результате изменилось около 180 файлов, а кодовая база выросла примерно на 18 000 строк кода после удаления 800 случаев использований Lombok. В среднем, каждая строка Lombok экономит 23 строки Java. С таким эффектом трудно представить Java без Lombok.

Резюме

Lombok — отличный помощник, который реализует новые функции языка, не требуя особых усилий со стороны разработчика. Конечно, проще установить плагин, чем обучить всех инженеров новому языку и портировать существующий код. Lombok не всесилен, но уже из коробки достаточно мощный, чтобы реально помочь в работе.

Ещё одно преимущество Lombok в том, что он сохраняет согласованность кодовых баз. У нас более ста различных сервисов и распределённая команда по всему миру, так что согласованность кодовых баз облегчает масштабирование команд и снижает нагрузку на переключение контекста при запуске нового проекта. Lombok работает для любой версии начиная с Java 6, поэтому мы можем рассчитывать на его доступность во всех проектах.

Для Grubhub это больше, чем просто новые функции. В конце концов, весь этот код можно написать вручную. Но Lombok упрощает скучные части кодовой базы, не влияя на бизнес-логику. Это позволяет сфокусироваться на вещах, действительно важных для бизнеса и наиболее интересных для наших разработчиков. Монтонный шаблонный код — это пустая трата времени программистов, рецензентов и мейнтейнеров. Кроме того, поскольку этот код больше не пишется вручную, то устраняет целые классы опечаток. Преимущества автогенерации в сочетании с мощью @NonNull уменьшают вероятность ошибок и помогают нашей разработке, которая направлена на доставку еды к вашему столу!

Источник