It's really nice to see movement here finally. Lack of value types has been one of the biggest performance pitfalls in Java for decades at this point
HexDecOctBin 1 hours ago [-]
What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?
DarkNova6 42 minutes ago [-]
Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.
Smaug123 12 minutes ago [-]
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
weinzierl 1 hours ago [-]
If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity.
I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
josefx 30 minutes ago [-]
Any project depending on Integer identity had years of warning that this change would come. Also given implicit primitive conversions and object pooling Integer isn't exaclty a prime candidate for object identity to begin with.
agilob 1 hours ago [-]
Java has a mechanism for Integer and Long objects caching using something that already looks like value object, cached objects can be compared using ==. hashCode of Integer already returns int, the boxed int value. Not much of value is lost.
swiftcoder 35 minutes ago [-]
Of particular note, all 1-byte Integers are interned, there is a pool of small Integers from -127 <-> 127 which are reused whenever possible.
I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...
Yes, massive respect for that type of perseverance on long term, important changes.
jurgenburgen 52 minutes ago [-]
Seems like a horrible way to work. Why could this not have landed as a large amount of smaller PRs in a more incremental fashion, maybe Java users could have gotten some value out of it earlier.
DarkNova6 47 minutes ago [-]
Out of all factors this certainly isn't it. If anything, more projects could learn from the way Valhalla was handled.
It started out as a highly invasive, highly disruptive and highly experimental branch that eventually turned into a beautiful specification that put semantics and performance payoff first and syntax seconds.
krzyk 47 minutes ago [-]
This is incremental. This change is the smallest possible one that could work.
There are more coming in later.
estebank 1 hours ago [-]
It's a project years in the making.
whytevuhuni 2 hours ago [-]
How much of Valhalla is this? 50% of it? 90% of it?
pjmlp 1 hours ago [-]
50% maybe.
There are other projects that depend having it in place, SIMD (vectors), reiffed generics, non nullable types.
The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language.
- Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari.
- Java has switch expressions, while JavaScript, despite its Scheme influence, does not.
- And now Java is getting value objects, while JavaScript's equivalent tuples & records proposal has been withdrawn.[0]
JavaScript was not developed as a fork of Java, but much of its basic syntax still resembles Java, so I think it's fair to compare them.
[0]: https://github.com/tc39/proposal-record-tuple
I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.
I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...
This is it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...
It started out as a highly invasive, highly disruptive and highly experimental branch that eventually turned into a beautiful specification that put semantics and performance payoff first and syntax seconds.
There are other projects that depend having it in place, SIMD (vectors), reiffed generics, non nullable types.