Без Lombok этот код не написать что ли? Если речь о двух классах с тремя свойствами, то в чём проблема написать все эти getter/setter вручную? Если у вас сотни или тыщи таких классов с десятками свойств, ну в IDE обычно есть средства автоматизации, которые за вас напишут этот boilerplate-код. Либо эта схема данных должна описываться в виде модели или на DSL, из которых нужный код может генериться. Не понимаю почему эта задача должна решаться именно Lombok'ом.

Эта задачка слишком тривиальная. Сделайте мне допустим редактор ER моделей с помощью Lombok. Нужно чтобы модели, которые рисуют пользователи хранились в базе на сервере, чтобы было API для работы с моделями, чтобы сам редактор моделей был на клиенте в браузере. Для этого нужно дофига кода:

1) Код для работы с базой (например, Hibernate'овые Entity-классы)
2) DTO для передачи на клиент
3) Мапинги между 1 и 2 в обе стороны
4) REST API или что-то такое
5) Клиентский код (JavaScript-классы)

Причём, если в этот редактор моделей я хочу добавить какие-то новые типы объектов (пусть это будет редактор каких-нибудь расширенных ER моделей или вообще других моделей), то мне нужно обновить код по всем этим 5 пунктам.

Толку от того, что Lombok избавит меня от написания getter/setter, создания билдеров и т.п. Мне нужно на порядок больше boilerplate-кода, совершенно разного. Один из вариантов - это описать схему данных в виде какой-нибудь Ecore-метамодели и сгенерить из неё весь этот код.

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

Я полностью за автоматизацию разработки, но Lombok - это автоматизация на таких минималках, что толку от неё вообще не видно.

PetroNotC Sharp,

в разных проектах использовали разные инструменты и подходы. Обычно схема такая.

1) Если есть много типового кода, значит можно его описывать в виде графической модели или придумать для этого специальный DSL, что позволит не писать лишнее.

Хоть для графических моделей, хоть для DSL нужно разработать метамодель. Метамодель описывает семантическую, смысловую составляющую нашего языка. Например, мы делаем какую-нибудь учетно-аналитическую систему и в ней полно совершенно типовых формочек, типового API для доступа к данным, типовых DTO-классов, Entity-классов и т.п. Соответственно в нашей метамодели мы описываем бизнес-сущности, которые нам нужны: формочка, поле формочки, визард (последовательность формочек), правило валидации и т.д. Описать всё это можно в любой нотации: на языке UML, в виде ER модели, в табличке в Excel перечислить сущности и атрибуты - вообще без разницы. Очень часто для этого используется язык Ecore . В статье последняя картинка это как-раз пример Ecore-метамодели. В нашем случае была бы метамодель описывающая атрибуты и связи между такими сущностями как формочка, поле, визард и т.п.

2) Затем для этой метамодели нужно разработать конкретный синтаксис: либо сделать редактор диаграмм ( раз , два ), на котором люди смогут описывать уже конкретные формы, либо описать синтаксис DSL ( раз , два ), чтобы они всё это делали в текстовом виде.

Для создания редакторов диаграмм можно использовать Sirius . По ссылке можно посмотреть много примеров разных нотаций для моделей. Для создания DSL раньше можно было использовать EMFText (он у меня в статьях описывается). Сейчас в основном используют Xtext , там смысл тот же.

На этом этапе у нас есть инструмент с помощью которого пользователи системы или разработчики могут описывать формочки или что там ещё им нужно.

3) Теперь из этих моделей можно что-то генерить. Для генерации кода из моделей можно использовать Xtend . Сейчас ощущение, что его забросили. У него было две ключевые особенности. Он позиционировался как улучшенная Java, но с появлением Kotlin и улучшением самой Java это потеряло актуальность. И второй момент: на нём очень удобно писать кодогенераторы - для этого он и сейчас продолжает использоваться.

Можно тупо писать кодогенераторы на Java, и часто так делают, но мне не очень нравится.

Для генерации кода из Ecore моделей можно использовать Acceleo .

Ещё один вариант - это не генерить код сразу из модели, а сначала преобразовать эту модель в другую модель, и затем последнюю сериализовать в текстовое представление. Например, мы в одном проекте описывали структуру документов на языке UML, описывали правила валидации этих документов на языке OCL . Затем генерили из всего этого AST (абстрактные синтаксические деревья) либо для XPath выражений, либо для Java кода. Правила преобразования исходного AST в результирующее описывали на языке QVTo . Полученное AST сериализировали в текст с помощью EMFText (либо сейчас это можно делать с помощью Xtext).

Вообще, есть полно и других инструментов для кодогенерации и т.п.


Смотрю на этот пост, на количество ссылок, аббревиатур и базвордов... Большой Синий Кит и так уже "наслаждается" моими умственными способностями, после этого поста на мне как на специалисте можно просто ставить клеймо профнепригодности.

Наверное, да, Lombok будет попроще. В принципе, Lombok - это тоже один из инструментов модельно-ориентированной разработки. Единственное мы не создаём какой-то свой язык моделирования или DSL. Разработчики Lombok уже создали его за нас и встроили в Java в виде аннотаций. Наверное это имеет право на существование, но я для себя не вижу смысла. Либо автоматизация на уровне Lombok не нужна вообще, либо нужна нормальная полноценная автоматизация, для которой Lombok не достаточно.

Если в проекте условно 2,5 класса, то почему бы и не написать. Если проект чуть сложнее, то я вообще не вижу смысла описывать эти классы в коде вручную. Мне проще описать их в модели или на DSL и сгенерить целиком вместе со всеми вспомогательными мэпперами (Entity-DTO), репозиториями, билдерами и т.п.

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

На мой взгляд Lombok - это тоже засирание проекта, лишние зависимости.