Типы-значения в Java

[@cypok]

Самый важный вопрос. В текущем виде дженерики — фича времени компиляции, и никаких типов-значений они поддерживать не будут. Но раз уж сказал «А» (типы-значения), то говори и «Б», поэтому рано или поздно дженерики переделают.

Это ваши личные догадки? И прогнозы в том числе?

[@leventov]

Из оригинала:

It is persistent irritant that generics do not work over primitive types today. With value types, this irritation will increase dramatically; not being able to describe List<Point> would be even worse. Still worse would be having it mean “today’s list, containing boxed points”.

Будет очень странно добавить типы-значения и потом жить с этим «dramatically increased irritation».

Вообще специализация примитивов просится давно и ИМХО даже важнее типов-значений.

[@yadobr]

Когда типы-значения появятся, JRE уйдет с еще большего количества компьютеров.

[@Maccimo]

С чего бы это вдруг?

[@SerCe]

Опущены детали предложения по реализации типов-значений на уровне байт-кода, что не очень интересно для большинства Java-программистов.

Как раз таки самое интересное :)

[@leventov]

Ну новые байт-коды. Или не новые. Тем кто не пишет свой язык на основе JVM или не поддерживает свою библиотеку для генерации кода вообще без разницы.

[@leventov]

Минусующие, расскажите, пожалуйста, как сильно вам помогло знание что при вызове лямбды, там, значит, стоит инструкция invokedynamic и она берет метод хендл. А не что-нибудь еще. Не понимаю, чем так интересен байт-код.

[@voronaam]

Не минусующий, но отвечу. Знание про invokedynamic очень упрощает чтение вывода «javap -c MyClass.class».

[@relgames]

Как я понял, это Case Classes?

[@cs0ip]

Case-классы отличаются от обычных только наличием генерируемых компилятором методов доступа к полям и объекта компаньона. А в памяти размещаются также как и обычные классы. Здесь же речь про возможность размещения данных на стеке, а не в куче. Помниться в скала-группе обсуждали возможность введения типов-значений и там высказывалось мнение, что они никогда не появяться в jre.

[@leventov]

Не похоже.

[@DarthVictor]

Нет, это Value Classes

[@darkdimius]

Да. Но mutlifield. И механизм добавления методов другой(у Scala — тут работает стандартный механизм implicit декораторов).
Однако Dotty с интересом наблюдает за тем, что будет в JVM.

Заодно это касается Universal Traits в Scala docs.scala-lang.org/overviews/core/value-classes.html

[@Throwable]

Сумбурно написано о ссылочном типе-обертке. Нужно, чтобы ссылочный тип можно было въявную указывать при определении переменной: как int и Integer.

— Типы-значения могут содержать и обычные объектные поля (которые не обязаны быть рекурсивно неизменяемыми, как сами значения), и поля других типов-значений. Но: не могут содержать поля своего же типа.
Спорно, т.к. стороны это нарушает труЪ-immutability.
Поля должны давать возможность быть ссылочной оберткой типа для реализации рекурсивных структур типа бинарного дерева:
_ByValue class Node {
Node? left, right; // Синтакс C#
}

— Тип-значение не может наследовать ни классу, ни другому типу-значению, от типа-значения ничего нельзя наследовать.
Спорно. Vector3D extends Vector2D… При присваивании просходит преобразование значения:
Vector3D v3 = ...;
Vector2D v2 = v3; // OK
Vector3D v3_1 = (Vector3D) v2; // Error

— Применение рефлексии к значению.
:( А в чем проблема? Это затруднит интроспекцию структуры, и динамическое получение данных. Половина фреймворков отвалится. Представьте, что в Hibernate нужно замепить value-type как Entity или @Embeddable…

— Присвоение переменной типа-значения null.
Если у меня поле имеет value-type, я должен указывать въявную дефолтное значение? Или default value определено как default value всех его простых полей?
public Vector3D v; // дефолтное значение Vector3D(0,0,0);

— Приведение к Object или любому супертипу.
Autoboxing к ссылочной обертке???

Почему не взлетит?
— очень толстое изменение, затрагивающее работу JVM практически на всех уровнях.
— текущие API Java не заточены под использование value-types. Потребуется либо полная переработка API, либо создание нового API (RTL 2.0).
— также многие библиотеки и фреймворки не заточены под использование value-types. Это новый концепт, который может польностью нарушить работу существующего функционала.
— все уже есть в scala

[@leventov]

1) Пожалуй да, но в Java пока нет понятия const ref и мне не очень понятно, как его делать или проверять.

2) Как раз логично. Иначе структура будет «бесконечной». Хоть в голом Си все равно придется ссылки делать. В лучшем случае Это будет

class  __ByValue class Node {
Node.__Boxed left, right;
}

3) Почитайте оригинал, там это обсуждается. Значение не таскает с собой ссылку на свой тип, поэтому на нем нельзя сделать полиморфный вызов.

4) То же, что и выше. Значит нельзя замапить. Либо ОРМы будут требовать самописные мапперы для типов-значений. Либо интроспектировать одно значение один раз, сгенерировать маппер и ходить им по необернутым значениям.

5) Второе, более того, дефолтный конструктор в типах-значениях будет запрещен по избежание разночтений. А методы должны учитывать что помимо инвариантов в полях могут быть просто нули в любом случае. Но присваивать null будет либо нельзя совсем, либо только для совместимости с существующим кодом типа point = null;.

6) Да

— Дженерики еще толще. Но надо, надо
— Текущие API живут как и жили. А кто пишет числодробилки, или какой-то код который генерирует миллионы мелких объектов и не может от этого избавиться, будет рад.
— В Java никогда не добавят то, что может «полностью нарушить работу существующего функционала».
— Судя по комментариям выше, нет. И я думаю почти невозможно прикрутить к JVM-языку нормальные типы-значения сбоку в обход JVM. Как, допустим, вернуть значение-кортеж из метода?

[@leventov]

удалено

[@dordzhiev]

Автор, может лучше называть их «значимые типы», как в MSDN? А то типы-значения как-то непонятно.

[@newcommer]

«Значимые типы» — это как-то не по-русски будет. Эти типы значимы, а на остальные можно забить :)
Хотя типы-значения тоже не очень подходящий перевод.

[@Colwin]

Лучше называть их структурными типами :-) IMHO, семантика и принцип работы очень близки к сишным структурам.

[@vit1251]

Скажите, а можно ли начать использовать родные многим типы вроде uint32_t, uint16_t и т.д. Я понимаю, что это конечно отдает чистым C/C++. Хотя конечно они только внесут еще больше хаоса в разработку, но часть алгоритмов сжатия и сдвигов можно будет на них выполнять.

[@ForNeVeR]

Можно, используйте. Примитивы int, long, short — это они и есть.

Для беззнакового сдвига есть специальные операторы, если нужно.

[@Colwin]

Микс знаковых и беззнаковых типов рождает хаос везде и всюду :-)
Не надо так делать в Java. Иначе на каждой арифметической операции придется думать об ошибках переполнения.

[@eXTreMeHawk]

(1) Я слышал, что Oracle одной из целей на java 9 ставит переработку взаимодействия с нативным кодом (JNI). (2) Если я правильно понял, то ближайший аналог «типов значений» в Си — это структуры.
(1) без (2) получится плохо, а значит у нас есть хороший шанс увидеть «типы значения» уже в java 9.

[@raid]

Язык для этого не приспособлен. Если в Java добавят типы-значения, то это будет уже не Java, а какое-то уродство, тем более без перегрузки операторов. ИМХО

[@Colwin]

IMHO, их могут добавить на уровне платформы, и не включать в язык (точнее, включать только для поддержки Generic-ов на примитивных типах).
Как промежуточный вариант вполне себе нормально.