Почему не всегда использование всех фишек подключаемых библиотек – это хорошо? 🌪
Зачастую, подключая какую-либо библиотеку к проекту, мы верим ей почти беспрекословно. Кажется, что всё, что мы подключаем к проекту, изначально не может содержать ошибок или недоработок.
Но это не так! Зачастую в библиотеках есть большое количество и неисправленных багов, и экспериментальных фишек ⚠️
Такая ситуация случилась со мной совсем недавно: я использовал библиотеку для автогенерации кода
Lombok, которая позволяет не создавать конструкторы, сеттеры, геттеры самостоятельно, а генерирует их за счет добавления аннотаций. Например, при добавлении @Getter над классом, эта библиотека создаст геттеры для всех полей этого класса. Очень удобно. И вот я разрабатываю класс-утилиту – вспомогательный класс, все члены которого статические, а экземпляры этого класса не могут существовать (создается приватный конструктор). Примером такого класса является
java.lang.Math. В этот момент мне приходит идея использовать аннотацию
@UtilityClass, которая как раз создает, и приватный конструктор и запрещает создание любых других конструктор. И более того, помечает класс final. Жизнь сладка! 🍏Ан нет! Я не прочитал документацию на эту аннотацию (а стоило):
https://projectlombok.org/features/experimental/UtilityClass
В какой-то момент сборка проекта начала падать, и я обнаружил, что причин для этого нет: IDE не подсвечивает ничего красным, да и сам проект выглядит рабочим. Почти час времени я потратил на то, чтобы выяснить, что если эта аннотация используется, то статический импорт из этого класса возможен только с использованием звездочки, а не с указанием конкретного метода.То есть (на примере java.lang.Math) так бы сработало:
import static java.lang.Math.*
А так нет: import static java.lang.Math.PI
Открыв документацию, мы сразу видим надпись «Experimental» и описание той самой проблемы, о которой я писал выше. Используя библиотеки – будьте внимательны к экспериментальным фишкам! ♨️