Как стать автором
Обновить

Комментарии 22

По версии 1.18.20 я делаю выводы, что инфа минимум на год устарела?

Краткое руководство по макропроцессору Lombok - если вы используете Java 17, вам не нужен Lombok.

Важный момент delombok может внезапно не работать. По крайней мере у меня такое два раза было.

В первом примере геттер для 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.

Lombok Plugin в IDEA курируется самой JetBrains. Это уже сильный аргумент в пользу будущего развития технологии (по крайней мере новые версии IDEA не останутся внезапно без него)

Большую часть предложенного функционала генерирует IDE. И делает это явно, то есть не прячет от вас (и всех остальных) реализацию, что на порядки улучшает поддерживаемость проекта.

Вообще, идея хитро править что-то там за сценой, что бы никто не догадался, это вполне очевидная проблема сама по себе. Ну а для берущих проект на поддержку новых разработчиков - серьёзная головная боль, устранить которую можно только одним способом - delombok.

А можно пример, когда деломбок прямо потребовался? Просто мой опыт говорит, что Ломбок хорош в 99 процентах (для меня пока на все 100, но процент стоит оставить, на непредвиденность)

Рефакторинг с целью сделать явным всё то, что ранее было закамуфлированным. Если IDE всё гененрирует, то держать смесь из нормального кода и чего-то непонятного - непонятно зачем.

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

Вообще нет желания что-либо защищать, но вот примеры, когда он мешает очень пригодились бы в практике.

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

Фи

@EqualsHashCode - когда есть цикличные зависимости, то приходилось подшаманивать :)

Совсем не горд за этот эпизод своей жизни.

Понятно, что перевод, но сколько же тут воды. Не рассказано ни про одну полезную фичу из exp блока (которые уже давно повсеместно используются)
Ни тебе https://projectlombok.org/features/experimental/Accessors (c chaining опцией), ни тебе https://projectlombok.org/features/experimental/Delegate

-__-

И еще вопрос, а нужен ли он сейчас вообще, в 2022 году, после многих нововведений в JDK?

думаю актуален пока остается достаточно большое кол-во компаний использующих 8-11 JDK

Если не ошибаюсь, то основное применение ломбока сейчас — это билдеры для dto-шек, и генерация конструкторов в компонентах спринга. Как с этим поможет новое jdk?

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

Есть еще файлик lombok.config, который позволяет выставить параметры по-умолчанию для аннотаций всех подпакетов. У меня, например, выставлено:

lombok.anyConstructor.addConstructorProperties = true
lombok.fieldDefaults.defaultPrivate = true

Первый параметр обеспечивает безгеморную десериализацию с Jackson-ом для immutable объектов, второй -- корректирует идиотское соглашение Java насчет package-private области видимости по умолчанию.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий