Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 401: Value Objects (Preview) merged to OpenJDK master

github.com

Post reply on HN
Print view View original

21–30 of 185 posts

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#21

Post by Smaug123 »

DarkNova6 wrote: post #17
HexDecOctBin wrote: post #9

What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?

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.

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.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#22

Post by jeroenhd »

DarkNova6 wrote: post #17
HexDecOctBin wrote: post #9

What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?

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.

We've had MMX for a while now, I don't think we need to wait much longer.

I don't really see why you would need specific hardware to express a type in a programming language, though.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#23

Post by MrBuddyCasino »

timmg wrote: post #15

I feel lonely in that: I mostly love Java as a language. 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.

Today it is a great language with a runtime that is unequaled. For heavy duty business backend server load, it is the standard choice, and rightfully so.

Do I love Spring? No. Do I prefer Typescript for my little side projects? Yes.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#25

Post by andrybak »

germandiago wrote: post #2

2934 commits OMG... huge work.

The way pull requests and commits work in the OpenJDK repository -- a bot squashes each pull request into one commit: https://github.com/openjdk/jdk/pull/31120#issuecomment-51378...

The final singular commit is cc278db (8389219: Implement JEP 401: Value Objects (Preview), 2026-07-31) https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#26

Post by agilob »

swiftcoder wrote: post #19
agilob wrote: post #8

Earlier quoted context omitted.

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.

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...

> Integers from -127 127

The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `

https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#27

Post by fulafel »

andrybak wrote: post #25
germandiago wrote: post #2

2934 commits OMG... huge work.

The way pull requests and commits work in the OpenJDK repository -- a bot squashes each pull request into one commit: https://github.com/openjdk/jdk/pull/31120#issuecomment-51378... The final singular commit is cc278db (8389219: Implement JEP 401: Value Objects (Preview), 2026-07-31) https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...

Is there a writeup on why they choose to destroy the history?

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#28

Post by spacechild1 »

DarkNova6 wrote: post #17
HexDecOctBin wrote: post #9

What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?

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.

IIUC value objects can have any size, it's just that 'reference flattening' requires the object to fit into a machine word. But this is only due to how Java represents object references and its atomicity guarantees.

Naturally, a language that properly supports value semantics does not have any of these limitations.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#29

Post by jerven »

jeroenhd wrote: post #22
DarkNova6 wrote: post #17

Earlier quoted context omitted.

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.

We've had MMX for a while now, I don't think we need to wait much longer. I don't really see why you would need specific hardware to express a type in a programming language, though.

Not for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.
Post reply on HN