Live data from Hacker News

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

github.com

31–40 of 185 posts

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

#31

Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability

Is there a theoretical reason why they can’t?

As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.

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

#32
post #27

Earlier quoted context omitted.

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?

You can recover the history using their tooling build on top of their bugtracker and GitHub. Specifically they capture the discussions and all small changes over time in their skara tools and are prepared to leave GitHub if needed. They had multi de adres experience and had multiple prior code repos. Still do if i understand as the Oracle team has the sun and bea code repositories pre openjdk preserved.

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

#33
post #16

It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript: - 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 tupl…

I've been annoyed too by the lack of Temporal support in Safari. It's supposedly behind a --useTemporal flag, but I've never been able to get flags to work even when launching the binary directly, and I can't find anything in developer options or feature flags settings either so like. Does it even exist at all??

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

#34

Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability

Is there a theoretical reason why they can’t? As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.

No theoretical reason; It's backward compatibility/internal technicalities, as they mention in the JEP.

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

#35

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.

It's mostly a performance question in order to adhere to Java's memory model.

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

#36
post #26

Earlier quoted context omitted.

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

That is a nice piece piece of knowledge! We have an Integer cache in our product, and the only reason that it hangs around is that it caches 0..1024 instead of -127..128. By setting this value, we could simplify our code, ever so slightly.

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

#37
post #16

It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript: - 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 tupl…

I've been annoyed too by the lack of Temporal support in Safari. It's supposedly behind a --useTemporal flag, but I've never been able to get flags to work even when launching the binary directly, and I can't find anything in developer options or feature flags settings either so like. Does it even exist at all??

It is enabled by default in STP, so presumably it will launch alongside the 27 releases.

Note Temporal was in the Ecmascript 2026 release back in March.

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

#38

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.

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.

That is exact problem.

Basically JEP401 guarantees that just adding "value" to the class won't change behaviour, which also means that you are not allowed to see object tearing, which requires atomic operations on the field.

Relaxing that would break safe publication rules, at least for Java.

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

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

java the language is amazing

the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere?

and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all

none of these are language problems

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

#40
post #16

It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript: - 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 tupl…

Java is to JavaScript what a Car is to Carpet. Very different beasts, though a lot of V8 work was inspired by Hotspot that's just because of common VM patterns not the syntax of the languages.
Post reply on HN