Комментарии 38
Планируется ли обзор DI решений (Guice, Dagger, HK2)?
+2
Беда начинается, когда требуется в одном проекте использовать и Lombok и AspectJ, они не очень дружат.
+2
А можете рассказать, что происходит? Я не сталкивался с такими проблемами, вроде AspectJ по идее работает уже с сгенеренными классами (или я ошибаюсь?), а сгенеренные классы Lombok не отличаются от обычных.
0
palesz.wordpress.com/2011/12/03/howto-maven-lombok-and-aspectj-together
1. javac compiles your .java files to .class files with lombok (generating methods, etc.)
2. aspectj regenerates your classes from the .java files without lombok
Но, к сожалению, предложенный по ссылке вариант у меня не сработал. И не только у меня, насколько можно понять из issue того же lombok — github.com/rzwitserloot/lombok/issues/995
1. javac compiles your .java files to .class files with lombok (generating methods, etc.)
2. aspectj regenerates your classes from the .java files without lombok
Но, к сожалению, предложенный по ссылке вариант у меня не сработал. И не только у меня, насколько можно понять из issue того же lombok — github.com/rzwitserloot/lombok/issues/995
0
Никогда не понимал людей кто юзает эту либу.
Для нового продукта можно выбрать лаконичные scala или koltin.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Нужно принимать язык таким как каким он есть.
Для нового продукта можно выбрать лаконичные scala или koltin.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Нужно принимать язык таким как каким он есть.
+1
Для нового продукта можно выбрать лаконичные scala или koltin.
Можно, но если вся команда привыкла писать на Java почему бы и нет. У scala многих пугает сложность, понятно, что можно писать как чуть лучшая Java, но если работать с чужим кодом можно ничего не понять. koltin пока не так распространен. Данная библиотека это компромис между новым языком и старым.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Кроме энтерпрайза есть просто старые проекты, которые по каким-то причинам использовали Java (скажем, микросервисы). С одной стороны переходит на новый язык сложно, с другой добавление библиотеки позволяет рефакторить старый код. Вообще, в Java энтерпрайз все больше переходит на Spring Boot и микросервисы, а это могут быть совсем не огромные проекты.
Нужно принимать язык таким как каким он есть.
Не согласен, так можно было вообще писать на Java 5 или Java 3. Язык вполне гибкая штука, в Java огромное количество открытых библиотек, которые тоже расширяют возможности. По такой логики их тоже не стоит использовать.
-1
Не согласен, так можно было вообще писать на Java 5 или Java 3. Язык вполне гибкая штука, в Java огромное количество открытых библиотек, которые тоже расширяют возможности. По такой логики их тоже не стоит использовать.
Вы передергиваете :) Речь ведь о языке в целом, а не конкретно какой-то её версии.
Генерация кода для DI вынужденная мера, тут я согласен.
В остальном, не западло прописать getter/setter потому что это Java, тут так принято.
Хотите нормальную аргументацию?
Для нормальной работы этого чудо модуля нужно ставить расширение для IntelliJ IDEA
Все эти генерации могут усложнить/замедлить скорость сборки проекта
Все эта магия вгонит в ступор первого же человека кто начнет разбираться в таком коде.
Ненужно пытаться нагнать всевдо-читаемость такими плагинами.
Если что, есть много других языков где ненужно писать getter/setter :)
+3
Если что, есть много других языков где ненужно писать getter/setter :)
Эм… Много? Что-то как-то в голову даже 5 не приходит.
0
Все эта магия вгонит в ступор первого же человека кто начнет разбираться в таком коде.
Спринговый @Compontent тоже вгонит, так что ж теперь, Спрингом не пользоваться?
+1
Аннотация @Compontent в отличии от аннотаций Lombok не дописывает код вместо вас, вот в чем разница!
0
Для человека, который этого не знает и та и другая аннотация выглядят магически и требуют времени для постижения того, что это такое и как работает, так что с этой точки зрения разница не велика. При этом, замечу, квикдок по аннотации Data первым делом сообщает: "Generates getters for all fields", плюс дает ссылку на сайт ломбока, что сильно помогает делу.
+1
Я не знаю как по другому еще донести до вас суть. Вы меня не хотите слышать, эта ветка зашла в тупик.
0
Суть вами сказанного, собственно, ясна. Просто есть иной взгляд на вещи, вот и все.
+1
Для меня лично не приемлем тот факт что без специального плагина для IDE с этим самым Lombok невозможно нормально работать. Это главная причина того, почему я не буду использовать это в своих проектах.
0
парсер, что ты делаешь, прекрати
0
Ну мне лично не нравится синтаксис котлина и скали, а джава с си подобным синтаксисом очень даже ничего. В принципе сгенерировать через alt insert в идее эти геттеры сеттеры тоже не сложно, но ломбок вообще шикарен.
0
Есть объект класса, нужно вернуть его часть в виде json — я создаю отдельную обертку, которая в конструктор принимает этот объект, и берет из него все нужное, после чего объект обертки прогоняется через jackson, и на выходе получаем json. Jackson, как известно, пользуется для конвертации либо публичными полями, либо геттерами, поэтому одна единственная аннотация Data над классом-оберткой быстро и не заметно экономит мне время. Еще одна аннотация @Slf4j позволяет мне работать с логгером даже не думая о нем. В общем не очень понимаю ваше не понимание, о каком «внедрении в бородатый энтерпрайз» вообще идет речь? Это же библиотека, а не фреймворк — если удобно, то используем, если не удобно, то не используем.
+1
Немного необычный подход с оберткой над объектом для генерации json.
Обычно делаются статические методы в хелпер-классе, например EntityHelper.toJson(myEntity)
В вашем случае идет совершенно ненужное создание +1 объекта обертки к каждой операции конвертации объекта в Json
Не буду спорить что ваш подход выглядит короче, круче :)
Обычно делаются статические методы в хелпер-классе, например EntityHelper.toJson(myEntity)
В вашем случае идет совершенно ненужное создание +1 объекта обертки к каждой операции конвертации объекта в Json
Не буду спорить что ваш подход выглядит короче, круче :)
+1
Ваш подход не подойдет в случае если нет однозначного соответствия Класс<->json. То есть в одном случае нужен json состоящий из некоторых полей класса А, в другом — из всех полей, а в третьем случае вообще должен быть композицией из A + B + C. Плюс мне нравится иметь возможность на вопрос «почему фронту приходит ЭТО вместо ЭТОГО?» пойти и подправить одну конкретную обертку гарантированно не затронув ничего по соседству. Я такие обертки вообще частенько создаю, как inner классы прямо по месту преобразования результата.
0
Нужно конечно видеть код, что бы подсказать альтернативный путь для решения этой задачи без дополнительных объектов-оберток.
Возможно что ваш подход хорошо подходит именно в вашем случае. Тут я спорить не буду.
Возможно что ваш подход хорошо подходит именно в вашем случае. Тут я спорить не буду.
0
А в чем проблема дополнительных оберток, кстати говоря? Формально понятно, лишняя сущность, но практически она маленькая, локальная и вопросов не вызывает. Стоит ли с ней бороться?
0
В вашем случае, на сколько я понял, это обертка возвращается вашим контроллером, по сути ничего, кроме эстетического момента меня не смущает.
Если же вы проектируете api какой-либо библиотеки, которую будут использовать сторонние разработчики, то тут я бы воздержался от таких конструкций. Разработчик может вызывать такой код в различных циклах миллионы раз, зачем провоцировать GC на лишнюю работу за зря?
Если же вы проектируете api какой-либо библиотеки, которую будут использовать сторонние разработчики, то тут я бы воздержался от таких конструкций. Разработчик может вызывать такой код в различных циклах миллионы раз, зачем провоцировать GC на лишнюю работу за зря?
0
Не совсем так. У меня выделена отдельная сущность «экшен», который с одной стороны может вызываться на выполнение фронтэндом, путем отправления по вебсокету специального сообщения, а с другой стороны в него интегрирован доступ к ядерным сервисам, которые обеспечивают работу самого приложения, и знать не знают ни о какой фронтовой части. То есть реализуя экшен (java код) на получение, к примеру, данных о работнике, которые на ядерном уровне распределены по нескольким компонентам, мы делам примерно так:
UserProfile userProfile = userService.getProfile(id);
EmployeeProfile employeeProfile = employeeService.getProfile(id);
после чего компонуем эти два профиля в одну entity, состоящую, скажем, из ФИО (взятого из userProfile) и количества рабочих часов в месяц (из employeeProfile), которую экшен и возвращает для дальнейшего превращения в json, и возврата фронтэнду. При таком подходе результирующий entity даже в виде inner класса в классе экшена смотрится довольно уместно.
А насчет библиотеки это да, тут согласен.
UserProfile userProfile = userService.getProfile(id);
EmployeeProfile employeeProfile = employeeService.getProfile(id);
после чего компонуем эти два профиля в одну entity, состоящую, скажем, из ФИО (взятого из userProfile) и количества рабочих часов в месяц (из employeeProfile), которую экшен и возвращает для дальнейшего превращения в json, и возврата фронтэнду. При таком подходе результирующий entity даже в виде inner класса в классе экшена смотрится довольно уместно.
А насчет библиотеки это да, тут согласен.
0
Пользую ломбок давненько, в основном Getter/Setter/ToString/Equal…
По моему удобно и Entity сокращаются в размерах в разы.
Только следить за циклическими зависимостями в ManyToMany и прочих подобных штуках надо путем использования exclude ну и с Equal… осторожно, в остальном просто супер.
По моему удобно и Entity сокращаются в размерах в разы.
Только следить за циклическими зависимостями в ManyToMany и прочих подобных штуках надо путем использования exclude ну и с Equal… осторожно, в остальном просто супер.
+2
Табличный формат совершенно не удобен, вы разве не видите?
+1
Выглядит круто, только вот один вопрос очень интересует: если физически в коде например геттеров/сеттеров нет (добавятся аннотацией), а ты их будешь юзать, не будет ли IDE их подчеркивать все время как ошибку? Она то не знает что они добавятся во время компиляции… И вообще как с ними автокомплит будет работать?
+1
НЛО прилетело и опубликовало эту надпись здесь
Для этой зависимости можно установить scope как provided, т.к. область действия функциональности ограничивается временем компиляции, что бы не тащить в билд эту либу.
+2
Года 2-3 использую ломбок только для Dto и Entity (для остального скорей не нужно). Крутая вещь. Одной аннотацией избавляешься от некоторой кучи проблем, например, достаточно просто изменить название поля или тип и ничего не надо больше делать (перегенерить сеттеры, хэшкод и пр.). Проблем ни разу не было, Dto'шки довольно краткие и красивые, на перфоманс не влияет.
Единственный минус, как выше писали, с AspectJ не работает, думаю, до сих пор не подружили. Сейчас попался такой проект и прям сильно скучаю по ломбоку, приходится руками лишние движения производить.
Единственный минус, как выше писали, с AspectJ не работает, думаю, до сих пор не подружили. Сейчас попался такой проект и прям сильно скучаю по ломбоку, приходится руками лишние движения производить.
0
"Много кода" - ссылка не открвается. Проверил в Firefox и Chrome. Может проще было бы оставить просто код?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шпаргалки Java программиста 10: Lombok