Комментарии 29
На мой скромный взгляд, ломбок — как костыль сбоку — если уж добавлять вкусняшек, но при этом оставаясь в java экосистеме — то стоит смотреть больше в сторону kotlin. IMHO.
а в чем костыль? код укорачивает, время экономит. в рантайме ничего не трогает. наоборот какая джава отличная, что можно её так расширять.
Пожалуй та же беда, что и с другими annotation processor-ами времени компиляции:
Если вдруг приходиться отладкой заниматься — с ломбоком начинает напоминать ад (хотя может сейчас уже плагины стали получше). Не совсем очевидно, что там он за код нагенерировал (прежде всего equals/hashcode).
Т.е если говорить о синтаксическом сахаре лет 10 назад — то ломбок был вполне себе ответом, но сейчас, когда есть лучшие решения… зачем делать такой шаг назад?
Если вдруг приходиться отладкой заниматься — с ломбоком начинает напоминать ад (хотя может сейчас уже плагины стали получше). Не совсем очевидно, что там он за код нагенерировал (прежде всего equals/hashcode).
Т.е если говорить о синтаксическом сахаре лет 10 назад — то ломбок был вполне себе ответом, но сейчас, когда есть лучшие решения… зачем делать такой шаг назад?
у меня много кода с ломбоком и обычно дебажить надо логику приложения, а не банальные геттеры. те моя практика показывает, что никакой боли нет.
я не думаю, что бизнес согласится выкинуть весь код написанный сотней разработчиков и начать все с нуля в Котлине. причем я то аргументов не смогу привести зачем надо тратить на это деньги. Лучше уж тогда все на Rust переписать :)
я не думаю, что бизнес согласится выкинуть весь код написанный сотней разработчиков и начать все с нуля в Котлине. причем я то аргументов не смогу привести зачем надо тратить на это деньги. Лучше уж тогда все на Rust переписать :)
Никто не говорить о том, что переписать всё на kotlin/scala/whatever. Я говорю о том, что если в 2019 начинать что-то писать — то вряд ли стоит выбирать Lombok.
И про Rust вы наверно пошутили…
И про Rust вы наверно пошутили…
А зачем переписывать? На Lombok (это фактически диалект Java) тоже никто бы не стал переписывать всё с нуля.
И там, и там можно писать новый код «в новом стиле» (без шаблонных геттеров и прочего), не трогая старый.
И там, и там можно писать новый код «в новом стиле» (без шаблонных геттеров и прочего), не трогая старый.
Ломбок легко встраивается в проект и не выглядит чужеродным. ну добавилось ещё пару джава аннотаций, делов то. те его можно всунуть в любой проект на любой стадии написания. а Котлин так легко не получится.
Точнее добавился ещё один annotation processor, который часть своих функций выполняет через дикие хаки.
И без поддержки в IDE c ним никак.
Kotlin точно так же всовывается в любой проект на любой стадии без проблем.
И без поддержки в IDE c ним никак.
Kotlin точно так же всовывается в любой проект на любой стадии без проблем.
Не скажу про котлин, а скажем всунуть в проект груви вам будет стоить добавления одного плагина в сборку maven (для gradle примерно тоже самое). IDEA это понимает, и поддерживает. И все. Вы можете писать классы на груви, получая большую кучу приятных плюшек. Нет, это не замена ломбоку 1 к одному, конечно. Это просто другой вариант упростить себе работу.
Подозреваю, что с котлином все точно также, плюс-минус детали.
Подозреваю, что с котлином все точно также, плюс-минус детали.
Kotlin не собирается под jdk > 8. Соответственно не получает фишек новых версий.
А каких фишек вам не хватает?
Все новые фичи рантайма (например, сжатые строки и G1) не зависят от языка. А в языке Java пока не появилось ничего нового, чего могло бы не хватать тем, кто перешёл на Kotlin.
С ходу нашел вот:
openjdk.java.net/jeps/280
bugs.openjdk.java.net/browse/JDK-8175883
Тут даже вопрос не в конкретных поинтах, а в том, что при развитии jdk kotlin не будет подхватывать оптимизации и улучшения.
openjdk.java.net/jeps/280
bugs.openjdk.java.net/browse/JDK-8175883
Тут даже вопрос не в конкретных поинтах, а в том, что при развитии jdk kotlin не будет подхватывать оптимизации и улучшения.
Порой нельзя так просто взять и убедить заказчика использовать котлин.
Может несколько параллельный к теме статьи вопрос. Однако, у java-господ нет усталости от обилия аннотаций в коде?
Казалось бы, делает жизнь проще, столько работы за собой скрывают. Но вот приходишь в какой-нибудь типовой проект с Lombok, Spring, Hibernate и что-нибудь ещё. Весь код просто увешен как ёлка с ног до головы аннотациями.
А молодые неокрепшие умы восхищаются, для них кругом магия, понять которую они не спешат. Зачем? Поставь аннотацию, всё сразу заработает. Не работает? Не хватает какой-то аннотации.
А мне всё больше кажется, что есть в этом что-то костыльное. Повышается ментальная нагрузка — глядя на аннотацию, надо вспоминать, что она добавляет или какую аннотацию ещё надо добавить. Как будто ключевых слов в языке прибавилось раза в два. Аннотации не нарушают принцип «явное лучше неявного»?
К Lombok, наверно, тут меньше всего претензий — он порождает довольно простой код, но тоже вносит свою лепту в общую копилку. Хотя можно же просто жмакнуть пару клавиш в IDEA для генерации геттеров/сеттеров и проч.
Всё чаще начинает казаться, что уж лучше я руками.
Казалось бы, делает жизнь проще, столько работы за собой скрывают. Но вот приходишь в какой-нибудь типовой проект с Lombok, Spring, Hibernate и что-нибудь ещё. Весь код просто увешен как ёлка с ног до головы аннотациями.
А молодые неокрепшие умы восхищаются, для них кругом магия, понять которую они не спешат. Зачем? Поставь аннотацию, всё сразу заработает. Не работает? Не хватает какой-то аннотации.
А мне всё больше кажется, что есть в этом что-то костыльное. Повышается ментальная нагрузка — глядя на аннотацию, надо вспоминать, что она добавляет или какую аннотацию ещё надо добавить. Как будто ключевых слов в языке прибавилось раза в два. Аннотации не нарушают принцип «явное лучше неявного»?
К Lombok, наверно, тут меньше всего претензий — он порождает довольно простой код, но тоже вносит свою лепту в общую копилку. Хотя можно же просто жмакнуть пару клавиш в IDEA для генерации геттеров/сеттеров и проч.
Всё чаще начинает казаться, что уж лучше я руками.
да, annotation driven development (ADD)
Java-господа разные бывают :) Поэтому аннотации не везде властвуют. Насчет «кодогенерации» — поддержу. Бездумное использование не повышает уровень разработки. Ускоряет — да. Но не повышает. Плюс, рано или поздно встанет вопрос: а правильно ли реализованы методы equals/compare/hashCode и почему на проде наш компаратор кидает эксепшены.
Есть такая усталость. Когда-то аннотации пришли на замену монструозным xml-описаниям, которые клалис рядом с классами, и свою задачу они решили (тем более, что в C# «атрибуты» появились очень быстро). Сейчас периодически на эти аннотации навешивают функционал, который там не нужен, в результате получаем слишком развесистые файлы .java, где на 3 строки с полями класса 23 строки с аннотациями :)
Полностью согласен. Меня в этом вопросе вообще далеко занесло: в своё время отказался от spring-boot (условно раз и навсегда), так как там есть ConditionalOnClass и ему подобные механизмы, в результате которых анализ нестандартных проблем и реализация нестандартного функционала ох как сложно даётся. Конкретный пример — в версии 1.4 (или более ранней?) нельзя было НИКАК добраться до ObjectMapper из FasterXML (который из JAX-RS — не путать с MVC), чтобы немного его «поднастроить». На раскопки тогда ушло пол-дня или день. Ну не предусмотрели на тот момент «магической аннотации», а создаваемый ObjectMapper в контекст (ни в Spring Context, ни в атрибуты сервлетов/сессий/запросов) не клался. И всё — птица «обломинго» заставила заменить фреймворк.
К чему это я всё написал: сам подход «всё сделает магия» приводит к тому, что за нестандартным поведением приходится ходить либо очень далеко, либо вообще отказываться. И если разработчики фреймворка этот сценарий предусмотрели — то вы добавляете «вторую магическую аннотацию или файлик», а если нет — то никак. Это всё хорошо для pet-проектов и «ща я за 5 минут сделаю докер-образ с годным приложением из 3-х сущностей», а в сложных проектах (где таблиц хотя бы 100 и бизнес-атрибутов на некоторых их них столько же) — увы…
Всё чаще начинает казаться, что уж лучше я руками.
Полностью согласен. Меня в этом вопросе вообще далеко занесло: в своё время отказался от spring-boot (условно раз и навсегда), так как там есть ConditionalOnClass и ему подобные механизмы, в результате которых анализ нестандартных проблем и реализация нестандартного функционала ох как сложно даётся. Конкретный пример — в версии 1.4 (или более ранней?) нельзя было НИКАК добраться до ObjectMapper из FasterXML (который из JAX-RS — не путать с MVC), чтобы немного его «поднастроить». На раскопки тогда ушло пол-дня или день. Ну не предусмотрели на тот момент «магической аннотации», а создаваемый ObjectMapper в контекст (ни в Spring Context, ни в атрибуты сервлетов/сессий/запросов) не клался. И всё — птица «обломинго» заставила заменить фреймворк.
К чему это я всё написал: сам подход «всё сделает магия» приводит к тому, что за нестандартным поведением приходится ходить либо очень далеко, либо вообще отказываться. И если разработчики фреймворка этот сценарий предусмотрели — то вы добавляете «вторую магическую аннотацию или файлик», а если нет — то никак. Это всё хорошо для pet-проектов и «ща я за 5 минут сделаю докер-образ с годным приложением из 3-х сущностей», а в сложных проектах (где таблиц хотя бы 100 и бизнес-атрибутов на некоторых их них столько же) — увы…
Lombok неплохая тулза, которая занимает свою нишу и имеет своих фанатов
но «возвращает величие Java», «реализует новые функции языка» — явный перебор, эта тулза лишь синтаксический сахар
все «проблемы» которые решает тулза спокойно решаются через автогенерацию в idea, но без диких хаков и ужаса при дебаге
но «возвращает величие Java», «реализует новые функции языка» — явный перебор, эта тулза лишь синтаксический сахар
все «проблемы» которые решает тулза спокойно решаются через автогенерацию в idea, но без диких хаков и ужаса при дебаге
Кстати вот да, недавно как раз читал эту статью в оригинале, а тут перевод! Спасибо, материал весьма дискуссионный. Не удержусь и оставлю коммент под оригинальной статьей:
Lombok sucks a butt. Kotlin data classes are way better and don’t require a ghetto compiler extension.
Lombok sucks a butt. Kotlin data classes are way better and don’t require a ghetto compiler extension.
пыль решили сдуть с книжных полок? Тогда надо сразу автору и про новые фишки в виде стримов и лямбд в Java 8 рассказать — с ними Java ещё величавее будет
Kotlin и data классы — это хорошо. Но, что если нужно генерировать кастомную функциональность. Тут альтернатив особо нет, если конечно все вручную не писать.
@FieldDefaults — очень крутая штука, тот сахар, которого так не хватает в Java.
Но у lombok есть и подводные камни. Связка Data + Hibernate (ManyToMany, OneToMany) выкинет вам StackOverFlow, при условии если не сделать ToString.Exclude.
Но у lombok есть и подводные камни. Связка Data + Hibernate (ManyToMany, OneToMany) выкинет вам StackOverFlow, при условии если не сделать ToString.Exclude.
Вопрос о совместимости lombok с модулями (Jigsaw в Java начиная с 9).
У меня есть два модуля:
open module db {
requires lombok;
requires .....;
requires .....;
exports models;
exports services;
}module taskManager{
requires db;
}В модуле db используется lombok и все методы там работают (модуль сделан как maven-проект, зависимости и импорты прописаны).
Но при запуске методов из taskManager получаю такую ошибку:
"C:\Program Files\Java\jdk-11.0.6\bin\java.exe"....
Error occurred during initialization of boot layer
java.lang.module.FindException: Module lombok not found, required by dbВ интернетах что-то ничего внятного не нашёл. Lombok вообще может работать с модулями? И где/как его прописать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lombok возвращает величие Java