Здравствуйте, ·, Вы писали:

vsb>>·>Во-первых, неясно зачем их видеть?
vsb>>Что значит "зачем их видеть"?
·>"2 — нет и это хорошо бы видеть" — зачем видеть отсутствующий геттер-сеттер?

Я про то, что 2 — не автосгенерированы, а написаны вручную с нетривиальной логикой. И эту логику хочется видеть. Если у нас .NET с его get/set, там это прекрасно видно.

Лично я это делал так: у меня были нетривиальные методы сверху, а автосгенерированные в отдельном блоке, помеченном специальными комментариями, которые идея умеет находить и сворачивать. Но это уже костыли.

·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.

Такой подход не пробовал, я пишу руками всё, автосгенерированные классы мне не нравятся (если только я сам не писал этот автогенератор).

·>Не, record вполне готов. Туда пихать ничего лучше не надо. Если что-то добавлять для билдеров, то это пусть лучше будет какая-то другая фича.

record готов для крошечных классов вроде Point(int x, int y). Хранить там 50 полей это безумие. Пока не будет синтаксиса для создания/изменения с указанием каждого имени. Собственно этот синтакс и обещают и скорей всего он будет. Но когда — :hz:

·>В c# {get;set;} — это встроенная фича языка, а в java это реализуется библиотечно с помощью Annotation Processor, как частный случай. Поэтому нет смысла пихать какой-то новый синтаксис.

Lombok это не библиотека. Это хак, который не должен работать и когда-нибудь перестанет. И тогда придётся запускать какой-нибудь lombokc вместо javac, как и должно быть по-хорошему изначально.

vsb>>lombok это да, это единственное, что хоть как-то спасает. Но надо понимать, что lombok это ещё один язык, похожий на Java. Я бы предпочёл писать на Java, а не на lombok.
·>Согласен. Впрочем создать dto+builder+withers+toString можно при отсутствии альтернатив.

Можно, но это костыли от недостатков языка, а не нормальная ситуация.

Я не считаю, что .NET идет правильным путем, суя в язык как сорока всё блестящее. И Java делает правильно, не торопясь с фичами. С тем же async/await они торопиться не стали и правильно сделали, сейчас вырисовывается более правильное решение. Но в некоторых случаях это приводит к перегибам.

В целом я думаю, что писать на Java 25 будет вполне приятно. Но пока — не очень.