Комментарии 22
По версии 1.18.20 я делаю выводы, что инфа минимум на год устарела?
Краткое руководство по макропроцессору Lombok - если вы используете Java 17, вам не нужен Lombok.
Важный момент delombok может внезапно не работать. По крайней мере у меня такое два раза было.
Ожидание: "Lombok. Полное руководство"
Реальность: "Здесь изложен необходимый минимум информацию"
P.S. У вас там опечатка
В первом примере геттер для surname в голой яве почему-то получился публичным. А еще Author заменился на User - недокументированная фича ломбока?
Скрипач не нужен, потому что есть язык на букву "K" :)
Kotlin еще начать использовать надо. Во многих проектах с большим количеством легаси властвует безраздельно какая-нибудь джава 1.7 и перейти на что-то другое - значит очень сильно вложиться
Я бы очень осторожно выбирал язык для долго играющих проектов (>3..5 лет). потому что сегодня JetBrains есть, а завтра ее кто ни будь купит и приоритеты поменяются и т.п.
Конечно для программистов меняющих место работы каждые год два это не принципиально.
Но вот мне пришлось переписать код с kotlin на java. Код модуля, написанный одним "энтузиастом, повышающим свою привлекательность на рынке изучением нового языка" Потому, что найти на его замену программера java+kotlin оказалось сложнее чем переписать модуль. Вовремя не остановил и пришлось время на это тратить.
kotlin - это исторически порождение проблемы старой Java в Android. При сравнении свежей Java + lombok аргумент "проще найти разработчика" становится более определяющим.
Либо "я пишу на kotlin (под Android) и ничего больше не знаю" либо "Я только Java знаю" в резюме. Исключения редки.
kotlin - это исторически порождение проблемы старой Java в Android.
Не нужно придумывать сказки. Kotlin ни для какого андроида не придумывали, а то что Kotlin взлетел на андроиде это был приятный сюрприз для самих JB. Никто это не скрывает, про создание данного ЯП есть достаточное количество материалов где раскрывается как все это было придумано. Популярность Kotlin на андроиде обусловлена как болью связанной с старой версией Java так и в целом куда менее консервативным сообществом адроид разработчиков.
Я бы очень осторожно выбирал язык для долго играющих проектов (>3..5 лет). потому что сегодня JetBrains есть, а завтра ее кто ни будь купит и приоритеты поменяются и т.п.
Как хорошо что крупные компании никогда не позволяют себе делать неожиданные вещи. Например делать JDK то платным то бесплатным. Судится за авторские права. Ой, извините это другое.
Не нужно придумывать сказки. Kotlin ни для какого андроида не придумывали, а то что Kotlin взлетел на андроиде это был приятный сюрприз для самих JB.
Ээ.. Вы когда что то читаете и отвечаете на это, о не надо отвечать на свои мысли. Я не говорил что Kotlin для Android придумали.
Если бы не было проблем с поддержкой в Android всех новых фич Java, то Kotlin 100% был бы одним из многих среди 10-ков свежепридуманных языков. Малоизвестных и скорозабытых. Преимущества/недостатки языка в таких случаях играют не первую роль. IMHO
Как хорошо что крупные компании никогда не позволяют себе делать неожиданные вещи.
Кстати.. А Kotlin то не на JVM движке случайно? (риторический вопрос). А JRE (если не в экосреде Андройд) то чье может быть? Не Oracle ли?
И можно подумать, есть 100% гарантия от такого же взбрыка JB.
Kotlin находится в open-source. Даже если JetBrains прямо сейчас исчезнет, у нас останется текущая версия, которую хоть как-то можно будет развивать.
А кто стоит за Lombok? Два мужика каких-то в постоянных разработчиках, если судить по разделу Credits.
Большую часть предложенного функционала генерирует IDE. И делает это явно, то есть не прячет от вас (и всех остальных) реализацию, что на порядки улучшает поддерживаемость проекта.
Вообще, идея хитро править что-то там за сценой, что бы никто не догадался, это вполне очевидная проблема сама по себе. Ну а для берущих проект на поддержку новых разработчиков - серьёзная головная боль, устранить которую можно только одним способом - delombok.
А можно пример, когда деломбок прямо потребовался? Просто мой опыт говорит, что Ломбок хорош в 99 процентах (для меня пока на все 100, но процент стоит оставить, на непредвиденность)
Рефакторинг с целью сделать явным всё то, что ранее было закамуфлированным. Если IDE всё гененрирует, то держать смесь из нормального кода и чего-то непонятного - непонятно зачем.
Если вам хочется защитить ломбок, то напишите статью, чем же он лучше простейшей кодогенерации, а задавать наводящие вопросы и узбекским методом добиваться признания вами любимой библиотеки есть, на мой взгляд, банальное лицемерие.
@EqualsHashCode - когда есть цикличные зависимости, то приходилось подшаманивать :)
Совсем не горд за этот эпизод своей жизни.
Понятно, что перевод, но сколько же тут воды. Не рассказано ни про одну полезную фичу из exp блока (которые уже давно повсеместно используются)
Ни тебе https://projectlombok.org/features/experimental/Accessors (c chaining опцией), ни тебе https://projectlombok.org/features/experimental/Delegate
-__-
И еще вопрос, а нужен ли он сейчас вообще, в 2022 году, после многих нововведений в JDK?
Есть еще файлик lombok.config, который позволяет выставить параметры по-умолчанию для аннотаций всех подпакетов. У меня, например, выставлено:
lombok.anyConstructor.addConstructorProperties = true
lombok.fieldDefaults.defaultPrivate = trueПервый параметр обеспечивает безгеморную десериализацию с Jackson-ом для immutable объектов, второй -- корректирует идиотское соглашение Java насчет package-private области видимости по умолчанию.
Lombok. Полное руководство