Пост​Value types: основное

​Value types: основное На прошлой неделе вышел билд с реализацией value types и основными оптимизациями. Это даже не превью версия, детали ещё поменяются, но первое впечатление составить уже можно. Вся информация есть в JEP 401. Сегодня расскажу основные технические моменты, отдельным постом напишу мнение про концепт идентичности, на базе которого стоит весь value тип. Интро В java 2 гендера типа сущностей — примитивы и ссылочные типы. К первой группе относятся int, long, boolean и тд. В таких переменных хранится само значение. Набор действий с примитивами ограничен, зато вычисления происходят с космической скоростью. К ссылочным типам относятся классы, массивы, интерфейсы и тд. Они хранят указатель на участок памяти, где находится объект. Классы содержат поля и методы, работать с ними приятнее, чем с набором чисел. Но есть минус - при работе с объектами нужно постоянно прыгать по памяти. Цель value типов - взять лучшее из двух миров: удобство классов и скорость примитивов. Добавляется ключевое слово value, которое ставится перед классом: value class LocalDate {    int year;    int month;    int day;    // конструкторы, методы } Поля класса становятся final, сам класс тоже final. Но главное, что в памяти список LocalDate будет лежать плоско, без лишних заголовков и прыжков по куче. Глядите на картинку👇 Слева список объектов, справа - набор value. Работа со списками обещает быть blazingly fast🚀 Value types прекрасно вписываются в текущие тренды. Сейчас через сервисы проходит море данных, которые в большинстве своём неизменяемые. Уплощение структуры даст буст в скорости обработки. Поэтому value types так ждут. Модификатор value уже получили 30 базовых классов: ▫️ обёртки примитивов: Integer, Long, … ▫️ Optional* ▫️ классы дат: LocalDate, LocalDateTime, … Классы выше - база, поэтому перфоманс подрастёт просто при переходе на JDK с value типами. Такое мы любим. Ещё немного странного/интересного: 🤔 value можно добавить абстрактному классу. Тогда наследники тоже станут value классами. В JEP написано, что наследники могут отказаться от value модификатора, но как - непонятно:) 🤔 value class vs record Record - final класс с final полями, идеальный кандидат, чтобы стать value классом по умолчанию. Но это не так, для records нужно явно прописывать value. В самом JEP объяснение сводится к утверждению Не каждый value класс можно сделать record Что, безусловно, верно. Но непонятно, почему неверно обратное. Остаётся только додумывать про обратную совместимость с уже существующими рекордс 🤔 String не стал value классом Опять же, могу найти техническую причину. Хэш строки вычисляется лениво, а в value классе поля должны быть final. Здесь помогла бы другая фича, которая сейчас в превью — StableValue, ленивая инициализация final полей. Но в JEP пишут, что дело в наличии идентичности (identity) у строки. Про концепт идентичности напишу отдельный пост, но если кратко: identity определяет возможность сравнения 2 объектов с одинаковыми значениями. Почему у строк есть identity, мне непонятно. Пул строк, дедупликация и прочие оптимизации явно не уважают право String на идентичность. Это только основное, на что точно следует обратить внимание. В тексте ещё очень много интересного, куча намёков на будущие фичи и оптимизации. Давно не читала JEP с таким интересом😊