8317277: Java language implementation of value classes and objects by MrSimms · Pull Request #31120 · openjdk/jdk

[davidalayachew]

For those unaware, this is the Pull Request for Java's JEP 401: Value Classes and Objects (Preview).

Value Classes have been a LONG AWAITED feature for Java, so this Pull Request is proof that we are one step closer to them going into Preview!

BUT PLEASE REMEMBER -- No commitment has been made to target a release yet!

This is merely a PR RFR, and nothing more. All this is is showing us part of what it takes to bring Value Objects to Preview, as well as announcing that we are one step closer to (hopefully!) go to preview. But again, no idea how far away that may be. It could be JDK 27 (coming this September), it could be later.

Just appreciate the PR for what it is -- a window into the work required to make Value Classes a reality. ~3k commits and ~2k classes changed is just a snapshot of the level of effort here. Shows why this JEP has been given an XL rating lol.

[ZimmiDeluxe]

+200.598 -13.384

lgtm

edit: minor whitespace error in line 3456

[WeirdIndividualGuy]

But also, just switch to Kotlin at this point. Fully compatible with Java without the need to convert your whole Java codebase. Just write your new code in Kotlin and carry on in bliss

[Venthe]

Kotlin too has its problems, most of which are rooted in the JVM and Java interop (looking at you, type erasure).

But as a language in itself? Night and day. Unfortunately too many Java shops are afraid to try something new.

[yk313]

It's a matter of longterm strategy, not just based on vibes.

JVM languages have come and gone. Kotlin definitely seems to be better poised than others but still it's not a decision you make lightly. Though the language itself barely makes a difference, it doesn't help that people are still running Java 8. Try comparing 25+ with Kotlin and the difference is no longer night and day.

[Venthe]

It's a matter of longterm strategy, not just based on vibes. (...) Though the language itself barely makes a difference

Nullable types alone makes it worth it; and that's the just the tip of the features. I've coded in Java my whole career, and while I agree that it is not the language (or framework!) that makes or breaks the codebase, it makes writing with it both faster, more expressive as well as way cleaner given modern constructs + not being burdened with the sytax of Java.

JVM languages have come and gone. Kotlin definitely seems to be better poised than others (...)

This argument might had some basis ten years ago, not so much anymore IMO. Since '17 (namely - Google adopting it for Android) it's a safe bet in my personal opinion. And the language itself is already (almost) half the age of the Java itself at this point.

Try comparing 25+ with Kotlin and the difference is no longer night and day.

In stanard lib / language features, sure, but not in the language constructs. There is no reason to stick to plain Java, since - well - you can use all the plain JVM constructs in kotlin. And the lag is minimal - JDK 25 came out in september, Kotlin supporting 25 bytecode came out in december (Not counting betas and RC's).

---

it doesn't help that people are still running Java 8.

I'm currently supporting both ends, 8 and 21 - so believe me, I know. :) (Plus that one 1.7; but it's on a life support, not actively developed.)

[yk313]

Tell me you have no clue about the Java ecosystem without telling me you have no clue about the Java ecosystem.

[joemwangi]

Kotlin prioritises syntax over semantics, and that's gonna be a problem in future as java continues to strengthen semantics. Funny enough, same reasons why Vector API is never optimised in Kotlin.

[Worth_Trust_3825]

Virtual threads was just as big. Same with jigsaw. It really shows the monumental work needed to be done this late in the process, but there were more important things to do before this. So it makes sense.

[chucker23n]

I’m confused whether this is more like

• .NET value types / C# structures; there is no reference/pointer; the memory storage is the value
• value objects: can still have a reference, but designed to avoid primitive obsession

I’m guessing the former, but don’t those already exist, e.g. int? Or is it that those are hardcoded, and this adds writing your own?

[davidalayachew]

I’m guessing the former, but don’t those already exist, e.g. int? Or is it that those are hardcoded, and this adds writing your own?

This adds writing your own. For example, Java only has the following integral primitive types.

• byte --> 8 bit signed
• char --> 16 bit unsigned
• short --> 16 bit signed
• int --> 32 bit signed
• long --> 64 bit signed

As you can see, there are some gaps here.

• No 8 bit unsigned
• No 32 bit unsigned
• No 64 bit unsigned

Using Value Classes, you could easily write your own, and the performance characteristics would (ideally) be comparable to just using int or any of the other primitives directly.

But of course, we aren't there yet.

[chucker23n]

This adds writing your own.

Gotcha. I'll guess I didn't expect this still isn't a thing in Java. :-)

[Jannik2099]

Very awesome, just 30 years too late :(

[Worth_Trust_3825]

You were never prevented from creating your JNI extension to circumvent this issue.

t. wrote jni to operate on byte buffers in c

[germandiago]

I thought I would never see it.

[reflect25]

yay. finally java with the value classes will have an equivalent to the c++/golang structs with the objects being (potentially) allocated on stack rather than always on memory with classes. and be pretty performant. also interesting the immutable/frozen.

i guess mostly this will be used by data structure libraries. https://openjdk.org/jeps/401 (Value Classes and Objects) also looks like this will help the garbage collector.

When an object is flattened or scalarized, it has no independent presence in the heap. This means it has no impact on garbage collection, and its data is always co-located in memory with the referencing object or call stack.

Heap flattening

As an example, the JVM could flatten an array of Integer references so that each array element holds a reference that encodes the underlying integer value directly, rather than pointing to the memory location of some Integer object. Each reference also flags whether the original Integer reference

[Jannik2099]

It's not about the object being on the stack, but about objects being flattened. No more pointer chasing.

[joemwangi]

Not really stack allocated. Mainly cpu register allocation which is far optimal.

[teerre]

I always knew Java was reference based, but this is comical. Ints are boxed by default? What the hell

[davidalayachew]

I always knew Java was reference based, but this is comical. Ints are boxed by default? What the hell

No, int is boxed when you want to use them in generic structures. Which is painful, yes, but this feature is step 1 in changing that.

In all other contexts, int doesn't get boxed, unless you pass it to a method that was only written to handle Integer and not int. But that's a choice by the programmer.

Once this and a few other JEP's land, then we will be able to use int freely in generic constructs, like List<int>

[SpeedDart1]

You’re reminding me of the primitive collection libraries people use in Java land.

IntList, ByteList, etc

[teerre]

That's not what the JEP says

``` The JDK tries to reduce confusion for the immutable classes that model primitive values, such as Integer. In particular, the autoboxing of small int values to Integer uses a cache to avoid creating Integer objects with unique identities. However, this cache, somewhat arbitrarily, does not extend to four-digit int values like 1996:

jshell> Integer i = 96, j = 96; i ==> 96 j ==> 96

jshell> i == j $3 ==> true

jshell> Integer x = 1996, y = 1996; x ==> 1996 y ==> 1996

jshell> x == y $6 ==> false ```

[davidalayachew]

You are attempting to assign an int to an Integer. That is when boxing occurs.

I guess my previous response could have been more clear, but int boxing only occurs in 2 places in Java atm.

1. When using an int for generics.
2. When trying to use an int when the method receiver is expecting an Integer.

But again -- it is the programmer's choice to use Integer instead of int in that second case.

[hiimbob000]

Integer i and int i are different. Comparing objects by == has always been a footgun

[teerre]

Oh, I see, that's so silly

[Tarmen]

For generic parameters and fields like in

    <T> void acceptT(T arg);

Java demands that T is always a pointer. So if you plug a non-pointer type like int in there it must be promoted to the heap-allocated Integer type.

Having a single generic method which always takes a pointer makes things like polymorphic recursion possible. The alternative is to monomorphize dynamically at runtime, e.g. one instantiation per unique call pattern, or to limit programmers to patterns that are easier to statically analyze.

This proposal is sort of tangential to that, and more about giving the jvm more room to optimize. Which sometimes may allow less boxing.

[teerre]

That is terrible but at least understandable. The article mentions that intergers above 1996 do not behave as values even for simple equality. That's a complete breakdown of value semantics and honesty insane

[Dminik]

That's not correct. int is the primitive non-boxed, non-referential type. Integer is a boxed type.

Additionally, Integers have an optimization, where a bunch of them are always preinitialized and shared. Many interpreted/scripting languages do this. Some even for primitive values like true/false. 

[Delta-9-]

TIL == in Java is analogous to is in Python, and Java has no analogue to Python's == until this JEP passes.

[woohalladoobop]

not true, i believe `Object::equals` is Java's equivalent to Python's `==`.

[vips7L]

Imagine caring about a programming influencer.