Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 29

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

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

Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 2: ↑1 и ↓10
НЛО прилетело и опубликовало эту надпись здесь

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

Всего голосов 6: ↑6 и ↓0+6

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

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью!

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

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


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

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

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

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

Всего голосов 2: ↑1 и ↓10
НЛО прилетело и опубликовало эту надпись здесь

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

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

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

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

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

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

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Насколько я помню из докладов на конференциях, главное преимущество records не в синтаксисе или кодогенерации, а в скорости работы. JVM работает с records как с примитивными типами. Например класс-рекорд ComplexNumber из двух double будет работать также быстро как и просто два double.
Комментарий пока не оценивали0

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

Всего голосов 1: ↑1 и ↓0+1

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

Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Изменить настройки темы

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr