How to become an author
Search
Write a publication
Pull to refresh

Comments 29

Сейчас читаю книжку — похоже в Scala нечто подобное сделано. Аргументы прямо у класса, из которых генерируются поля, основной конструктор и возможно еще что-то.
Total votes 1: ↑1 and ↓0+1
Если вы про case classes в Scala, то они всегда иммутабельные. Records в Java таким свойством не обладают. А в остальном похожий подход.
This comment wasn’t rated yet0
Можно написать class X(var x:Int) и получить класс с мутабельным полем.
Но все-таки лучше все делать иммутабельным.
Total votes 1: ↑1 and ↓0+1

Я конечно очень люблю скалу, но все-таки. По умолчанию в кейс классах свойства val, но можно явно написать var и будет сгенерирован сеттер. А вот в рекордах, насколько я понял JEP, все поля как раз таки генерируются как final.

Total votes 1: ↑1 and ↓0+1

Ближе к kotlin, а вообще хорошая идея.

Total votes 2: ↑1 and ↓10
UFO just landed and posted this here

Java не С, Парламент не Ява

Total votes 6: ↑6 and ↓0+6

Я просто хотел сказать, что конструкторы есть в любом классе, независимо от языка. Классов нет, нет конструкторов, как в С. В плюсах, да и тем более в шарпе они конечно есть. Ну тут еще можно холивар развести, что шарп это конечно неудачная копирка Java

This comment wasn’t rated yet0
UFO just landed and posted this here
Спасибо за статью!

Не джавист. Но выскажусь)
Подобный синтаксический сахар позволяет сделать все быстро(если не сказать побыстрее), в ущерб качеству. Пока ты пишешь вручную все эти «рутинные строки» кода, у тебя есть время подумать о названиях, типах, лучших решениях — ты «вкладываешь душу».
Total votes 6: ↑2 and ↓4-2

Пока ты пишешь вручную все эти рутинные строки кода — ты не вкладываешь душу, та задалбываешься и теряешь концентрацию.


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

Total votes 4: ↑4 and ↓0+4
Во-первых, быстро — не всегда в ущерб качеству. Не думаю, что кому-то приятно вручную писать геттеры и сеттеры. Как раз при их написании вручную можно добавить багов.

В-вторых, статья немного приоткрывает «внутренности» и возможности «донастройки» стандартного решения.
Total votes 1: ↑1 and ↓0+1

Кто не хочет писать руками геттеры и сеттеры, уже давно этого не делает. Это делает Lombok.

Total votes 2: ↑1 and ↓10
UFO just landed and posted this here

То, что описано в статье Lombok делает без всяких глюков.

Total votes 3: ↑3 and ↓0+3
Он бывает отваливается если не успели обновить под новую версию JDK или Gradle например… в самый неподходящий момент (как вот тут github.com/rzwitserloot/lombok/issues/2238… сам сталкивался).
Все таки Lombok — это дополнительная зависимость, может быть дополнительная головная боль, когда надо только всего лишь Record

+ Record будет работать с pattern matching механизмом в будущем (в 14еа можно пощупать на instanceof)
This comment wasn’t rated yet0
Дело в том что вместо Record лучше бы сделали перенос Lombok в Java standard lib (пожалуйста, не цепляйтесь к термину). Уберутся проблемы с несовместимостью версий, добавится адекватная flexibility и т.п. ES уже несколько версий подряд не стесняется добавлять lodash/underscore, а для Java это дело принцыпа? Тут недавно была статья о performance и testing для самой Java, но в первой итерации никто не ждёт ничего сверхестественного.
This comment wasn’t rated yet0
Конечно есть много полезных вещей (не только в Lombok)… и я, возможно, тоже хотел бы видеть больше нововведений (… немного остепенился наверное).
Но и это уже серьезный шаг для такой платформы как Java (backward compatibility, libs compatibility, next features roadmap: pattern matching etc.).
Нам же Lombok не запрещают, когда нужна тяжелая артиллерия :)
This comment wasn’t rated yet0

Пожалуй, самое заметное ограничение с записями в том, что нельзя объявлять собственные поля. Что в свою очередь означает, что нельзя сделать "ленивые" свойства, по аналогии с lazy val в Scala или by lazy в Kotlin. И в скале, и в котлине я регулярно пользуюсь этими фичами, очень жаль что в джаве эквивалент с записями сделать не получится :(

This comment wasn’t rated yet0
Да, замена ломбока на готовые инструменты языка — это очень хорошо. А есть ли информация, как будут обстоять дела с сериализацией/десериализацией? Зачастую кучку таких классов приходится писать для работы с api-шками и представления объектов в виде json
This comment wasn’t rated yet0
да, было бы еще хорошо, если бы продумали простое клонирование
This comment wasn’t rated yet0
Да, замена ломбока на готовые инструменты языка — это очень хорошо.

А чем это хорошо? Ломбок таким образом всё равно не заменишь, он делает сильно больше, чем java records. Инлайн классы — вот они точно нужны, ради них можно перейти на новую версию джавы, а рекорды заменяются аннотациями "@Value" и "@AllArgsConstructor"

This comment wasn’t rated yet0
UFO just landed and posted this here
Насколько я помню из докладов на конференциях, главное преимущество records не в синтаксисе или кодогенерации, а в скорости работы. JVM работает с records как с примитивными типами. Например класс-рекорд ComplexNumber из двух double будет работать также быстро как и просто два double.
This comment wasn’t rated yet0

То, о чём вы говорите, называется inline classes. Если бы их зарелизили, сейчас бы весь Хабр на ушах стоял.

Total votes 1: ↑1 and ↓0+1

Спасибо за перевод, небольшой + в копилку знаний. Интересно, как скоро проекты будут переводить на java 14?)

This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr