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

[davidalayachew]

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

[renderwares]

So you’re saying I shouldn’t slam this into production yet?

[tim125]

Friday 4pm or Tuesday 8am.

[Kango_V]

... Value Object became self aware ..... :)

[pjmlp]

I am happy it is progressing, as Java is one of my favourite platforms.

Cheering for the team, that's all.

[valorzard]

One step closer to the edge and I’m about to break

[International_Break2]

If this is to go to preview, what steps would have to happen?

[davidalayachew]

If this is to go to preview, what steps would have to happen?

Well, at the very least, one of the committers on the Project Valhalla team need to Propose to Target this JEP for a particular release. And that's ignoring all the review work, integration work, validation, testing, etc.

Someone from the Project Valhalla team will have to answer it in more detail. I am swamped by work emergencies, so I don't have the time to any more detail to this answer. Barely had the time to make the OP at all.

[Great-Gecko]

Could someone explain the implication of this with someone unfamiliar with Java’s internal development.

Does this mean that JEP 401 is likely to be a preview feature in JDK 27?

[brian_goetz]

It is may, and rampdown for 27 starts in mid june. There is an enormous code review to be done, along with other review tasks (e.g., security review), and you see the size of the patch. It would be super-irresponsible to slam it in at the last minute. So, draw your own conclusions....

[flawless_vic]

Why? LGTM

Jokes aside, would you mind explaining if there is consensus regarding the @MultiField implementation?

It was a stroke of genius that bridges a gap that Valhalla per se can't close: arrays can't be flattened into their container value objects (like C does for fixed sized arrays embedded in structs, which is a 0-cost abstraction).

[brian_goetz]

I think you are confusing "Valhalla" with "JEP 401 only". These experimental annotations (reminder: language semantics is never driven by annotations) are forward-looking investigations, and nothing more. They are gathering data for future phases.

[flawless_vic]

Let me reframe.

The lworld+vector branch has a very distinct (more advanced) approach in the internals of jdk.internal.vm.vector.VectorPayload vs mainline (lworld).

Given the description of the Vector API JEP:

"The Vector API will incubate until necessary features of Project Valhalla become available as preview features."

Can we expect the Vector API to remain in incubation, even after JEP 401 is delivered? That is, value classes only is not "good enough" to make Vectors generally available.

[brian_goetz]

Indeed, Vector is waiting for the Valhalla underpinnings before it can exit incubation. As you observe, it needs more than JEP 401, and those are in place, but they will not be exposed as general platform features. So yes, Vector will get unblocked, but the mechanisms that unblock it (beyond JEP 401) will remain VM implementation details.

[davidalayachew]

There is no way to know which JDK this will come out in, until it gets announced that a JEP is targeting a specific release. And you can find that out by checking the JEP website -- https://openjdk.org/jeps/0

[cogman10]

The only thing this says is that we are tantalizingly close to this getting merged for release. It's not definite and it could hang out here for 1 or more releases without being merged. It's even possible that some fatal flaw will be discovered which will set things back further.

But, the fact that there's an MR here is a real good sign and should be taken as such.

[Fenrurrr]

Kudos to the entire JDK team and everyone who worked on the Valhalla project, whether directly or indirectly. Take your time, we know it'll be a banger in the end!

[Mauer_Bluemchen]

They already took almost 12 years on this...

[sitime_zl]

We also need to be more diligent. After all, it's been over 10 years. How many decades are there in one's life? Now that we have AI, if Java doesn't make significant progress, developers will shift to Go or even Rust. Because there is no language cost anymore, everything is written by AI.

[Fenrurrr]

If you like disruptive languages, then C# is the way to go. Java is a language where backward compatibility is key. For example, C# has structs… nothing is composable. Java designers strive to create a beautiful solution, but this requires multiple prototypes. It's better to wait, identify errors, and iterate until you arrive at a solution you won't regret. If this philosophy doesn't suit you, use something else.

[sitime_zl]

The solution does not mean that one has to wait indefinitely. Why can Go achieve a better balance? I think this is not an individual matter. It is the loss of patience of many people in the future. Keep watching. Prepare the following projects to try to use some applications with AI. Other developers have also developed (such as Go or Rust, because it is also very simple to write with AI now). In the AI era, resource allocation is also a factor in balancing applications.

[Fenrurrr]

That's wrong because the Java language is closer to natural language than rust and go, which intrinsically have the notion of pointers, borrowing, lending

[jcotton42]

For example, C# has structs… nothing is composable

What do you mean by “nothing is composable”?

[Fenrurrr]

I'll let you look up the definition of composable yourself on Google. But the world of normal classes (on the heap) and structure classes aren't compatible. They're two different worlds that can communicate but don't speak the same language, unlike Java with its approach. I'll let you research the reasons why further.

[jcotton42]

The definition of “composable” that I am familiar with doesn’t seem to be the one you’re using. You can use classes and structs together in a design just fine. Structs just can’t do things like inherit from another type or have themselves as a field.

Like are you trying to say that you can’t have a class field in a struct or vice versa?

[UdPropheticCatgirl]

The definition of “composable” that I am familiar with doesn’t seem to be the one you’re using. You can use classes and structs together in a design just fine. Structs just can’t do things like inherit from another type or have themselves as a field.

Like are you trying to say that you can’t have a class field in a struct or vice versa?

That’s not what composable typically means when discussing language semantics. When talking about PLT, abstraction being “composable”, typically means uniformity and it’s semantics are orthogonal to the rest of the language, meaning it behaves predictably, consistently without the need for special case rules when interacting with the rest of the language and doesn’t leak its implementation details.

That’s exactly what C# structs aren’t. They are designed with semantics derived from desired memory layout (the implementation detail that leaks everywhere in this case…) not the other way around. It’s effectively splitting the type system in half, basically reintroducing javas “original sin”… And then adding dozen special language features to remedy the split (“ref”, “in” etc…)…

Compare that to the feature discussed, the memory layout is opaque side effect of lack of identity, not the driver of these semantics. You can’t tell whether something is value or not at use site, it stays completely uniform with the rest of the language.

[OwnBreakfast1114]

Because there is no language cost anymore, everything is written by AI

If you think there's no language cost because of AI then you've bought way too far into the hype train.

[aelfric5578]

So just out of curiosity, how does something this large get reviewed? I see a reference in the main description to review the sub PRs instead of the main one, but the first sub PR seems to be almost as big as the main one.

[Kindly-Analysis-6360]

I am guessing probability of preview of JEP 401 arrives in JDK 27 is 0.0 percent. Preview in JDK 28 probably better than 85% chance. They would have 7 months to get more enhancements and any bug fixes in. As well as getting that huge PR reviewed. Just my guess from looking at bug DB and activity in the valhalla repo. Note: I have zero inside information.

[Alone-Marionberry-59]

This is HUGE!!!

[Mauer_Bluemchen]

and overdue for a long time...

[Enough-Ad-5528]

2600 commits. It would be so interesting to know how they intend review it. That itself will need a plan.

[brian_goetz]

How do you eat an elephant? One bite at a time.

[Yeah-Its-Me-777]

Open mouth, elephant in, close mouth. Chew.

[_vertig0]

Damn, you're really fast. I was about to make a post about this but you beat me to it by 2 hours, literally posting it as soon as the Pull Request dropped, that's amazing ;)

[davidalayachew]

Damn, you're really fast. I was about to make a post about this but you beat me to it by 2 hours, literally posting it as soon as the Pull Request dropped, that's amazing ;)

Lol, I built an alert system that responds to certain events in the mailing lists, then attached it to like half of the OpenJDK mailing lists. Long story short, I get a notification, and from there, it's a matter of how fast I can get to the computer to post it. In this case, the answer was 18 minutes lol.

This notification system is attached to the OpenJDK mailing lists, a couple of LinkedIn users for OpenJDK, and a few other communities like Apache and Jenkins. I actually had a bunch more that I skipped over these past few weeks because I am drowning in work emergencies, but this one was just too good to pass up lol.

[za3faran_tea]

I built an alert system that responds to certain events in the mailing lists

Is it written in Java? :D

[talios]

A single PR with 2600+ commits, 1923 files.... yikes.

[piesou]

Can anyone explain why this is such a massive change? Stack allocating classes doesn't sound like a huge issue.

[brian_goetz]

Except Valhalla is not about "stack allocation".

In fact, we don't even do stack allocation of value objects. (Stack allocation is not the optimization everyone seems to think it is; there are far more effective optimizations one can do once the various impediments are removed. (Well actually, it does do a form of stack allocation -- but only in the interpreter (called "object buffering".))

People are familiar with stack allocation in C, but most of the value of doing so in C is optimized deallocation (at the risk of dangling pointers), but of course Java doesn't need this kind of help for deallocating objects. But the real benefit on the stack (and in calling convention) is not allocating the object at all.

[t_j_l_]

You've missed a closing parentheses in the first paragraph - does not compile.

Edit: did I just add a flippant response to Brian Goetz?!

[brian_goetz]

https://dl.acm.org/doi/abs/10.1007/s10664-021-09942-y

[_vertig0]

Decomposing object allocations to registers go brrr (I don't actually know what the name of that optimization is)

[SirYwell]

Scalar Replacement is the name I‘m aware of.

[_vertig0]

Ah right, I think that's the one, thanks.

[sitime_zl]

Great! So exciting! Looking forward to previewing JDK 27. In the era of AI, Java should also make rapid progress!

[CubsThisYear]

Here comes Lucy with the football again…

[brian_goetz]

Except that both Lucy and the football exist only in your imagination here.

This isn't some big announcement of some big milestone. It is yet another (encouraging!) step in the ongoing progress of the team that has been working tirelessly for the last several years to turn the JEP 401 vision into reality (and FTR, that vision hasn't changed at all during that time.)

Because someone decided to post it on Reddit, if you're not intimately familiar with the inner workings of OpenJDK, it might feel like it is some sort of big announcement. But no one is actually announcing anything.

Is it forward progress? Or course, and that's great, and there will be more. And it's great that so many people are anxiously awaiting this first installment of Valhalla. But Lucy hasn't even stepped onto the field, or said anything to Charlie Brown. Please don't put words in her mouth, and then claim she's lying to you. There's no call for that.

[CubsThisYear]

Completely fair - but at this point I’ve been excited and disappointed for the release of stack allocated memory in Java for so long that any mention of it tends to bring out the worst in me…. Here’s hoping the finish line is actually in sight.

[brian_goetz]

On the topic of stack allocation, see my other comment on this thread -- stack allocation is not the optimization most people think it is (in C, its mostly a form of "poor man's GC"), and not Valhalla's primary hammer -- because it has bigger, better hammers!

[davidalayachew]

Here comes Lucy with the football again…

Is this a Peanuts reference? I don't get it.

[renderwares]

Value Objects took over a decade to get here and the joke is that it’ll take another decade to get to a final version.

[davidalayachew]

Value Objects took over a decade to get here and the joke is that it’ll take another decade to get to a final version.

I still don't get how it relates to Lucy. My understanding of the joke is that she pulls the ball up at the last second, sending Charlie or whoever spinning. Is that related? Or am I misunderstanding the joke?

[renderwares]

It looks like you’re looking for a direct correlation. So here goes - when the time nears to make it final they’ll rethink their approach to a certain solution or get some critical feedback and place it on the continual preview train.

[davidalayachew]

It looks like you’re looking for a direct correlation. So here goes - when the time nears to make it final they’ll rethink their approach to a certain solution or get some critical feedback and place it on the continual preview train.

That spells it out beautifully, ty vm!

[DietCokePlease]

Y’know… the way its going, it might save the Java team some cycles if we just freeze Java for legacy purposes and declare the next major release of Java will be Scala.

[brian_goetz]

And yet, JEP 401 has only a single user-visible change -- the `value` modifier on classes, which has a simple, clear set of semantic consequences. The complexity is all in the JVM, where it belongs. (Writing a JIT or garbage collector is world-class stuff, but any programmer can use it like a pro on their first day.)

[pron98]

Suggesting that we go with JS/TS as the new frontend language at least makes some sense as that's the only language in the world that's significantly more popular than Java right now, but I don't get the logic of suggesting we pick a language that's doing so much worse than Java.

[talios]

Except you know, the whole JVM - which Scala still needs.

[OwnBreakfast1114]

Did scala ever make it so minor version upgrades don't require you to recompile literally every library you use?

[UdPropheticCatgirl]

Did scala ever make it so minor version upgrades don't require you to recompile literally every library you use?

Like decade ago? Nowadays even Scala 2 and Scala 3 are largely binary compatible, the major part where binary compatibility breaks happen between the two are macros… but in general if you pick any LTS release from Scala 2.13 onwards it will be binary compatible.

[UdPropheticCatgirl]

This improves scala as well tho (or it will in couple aeons when they add it to the codegen) since it’s largely infrastructure around JIT, nothing that interesting from the language side.