> No headers per element. No pointers. No jumping around the heap.

that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it.

[1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

The obviously used too much AI, I stopped after 2 paragraphs

> This is exactly the moment where non-nullability stops being cosmetics and becomes a lever for performance.

Looks like they just missed the `!`. It should be `Point![]`.

> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here.

I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start.

Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentre/compute business at this point, with appendiges for its legacy activities and a vast overhang of debt.

I sometimes wonder if the only parts of Oracle that are still profitable are the Legal and Lawnmower divisions.

so your complaint is about the blogger, not the Java language?

also, null markers are coming too: https://openjdk.org/jeps/8303099

Its just that they have to deliver things incrementally. This PR that introduces value classes/objects is already 200k lines long.

They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.

That said, we've been gnawing on this limb for a while...

Nullable is just a different loadout state in Railway Orientated Programming. So, no reason to put different flavours of state into the language directly, when its a solved thing since (checks slides) 2012. There is just rails - going to A or going to B, depending on the trains loadout.

If you have language-wars about a concept going in and out of existence, that is a hint that there is demand and the language does not properly handle the demand or when it handles it, it creates mental overload.

> Value

> Errorstates

  > Null

  > IoExceptions

  > WeirdOsStatesNeededToHandleUpstairs

As the pythons said: Get on with it!

> it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly.

I think you've missed what this is referring to. It isn't about null safety (which is orthogonal) but about having reference/value projections analogous to Integer/int.

What the Valhalla team ended up doing is, instead of having two projections for each type, one with identity and one without, value types never have identity and so Integer and int are synonymous, and the memory layout is determined automatically based on context and optimisation decisions. This is why the semantics of == for the primitive wrappers (like Integer) were changed, as they now don't depend on whether the "reference projection" or the "value projection" is used.

> There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing".

This is not what happened here.

This is mainly for performance and memory layouts, it would not have improved safety guarantees of java.

> very little faith that Java can be steered in a sensible direction here.

What? It’s been getting better with each release. Valhalla brings features that address key problems, and they didn’t rush to it either.

Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and the issue of value classes in generics is the second phase so is being pushed far into the future.

But a huge mistake (IMHO) was not having nullability part of the type system. You can still do this with type erasure.

Anyway, I read your comment as "nullability isn't complex" (paraphrased) but that's not the author's point. What's complex is having a value class and a regular class of every class and you don't necessary know which one you're dealing with at the language level.

C++ is a great example of this. You can create an object ont he stack or the heap and that's really what we're talking about with that proposal. And that's a nightmare. Combined with pointers it meant you never knew if you could free something or not and that ownership had to be passed around with vague comments like "// retains ownership".

Anyway, the whole article is a great tale of how difficult it is to retrofit things later and how difficult it can be to fix mistakes later (eg java.util.Date).

Yes, in this respect Java is 100% doomed. They've made a terrible decision and they're sticking with it for the sake of "consistency".

> If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle)

Whether you like oracle or not, this is simply not a correct description of Java's history. It was brought up by loving parents, who due to financial problems had to put Java into a foster home where she was neglected.

But later it was adopted by new, loving parents (Oracle) and she bloomed and become a healthy and stable adult.

Like, it was Oracle that completed the open-sourcing of the platform, making OpenJDK the reference implementation. They also open-sourced the previously proprietary jfr, mission control etc tools.

They also managed to keep many of the original members of the language team, which is quite rare during these acquisitions, and Java has seen a huge improvement both on the language and runtime front.

It was neglected during its last few years at Sun. Oracle started moving it forward at never before seen pace, while mostly maintaining backward compatibility (unlike .NET that "did things right from the start", which is what .NET Framework/.NET Core/.NET split/rewrite is according to some in this very discussion. And .NET had Java to copy and learn from, but still fucked up.)

Same with MySQL, btw. "Dead" according to this site, risen from the dead under Oracle for those who actually know it.

> If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle).

> Neglected and unloved till JDK 8, its basically been playing catch up.

These two statements are contradictory. The last Java version under Sun was in 2006. Oracle bought Sun in 2010. JDK 7 came out in 2011 and JDK 8 in 2014.

The team largely remained the same, and the main difference was that Oracle ended the neglect and funded us more, which is why Java picked up the pace after the acquisition.

> its basically been playing catch up.

Catch up with who or what? There are only two languages in the world as popular as Java or more: JS/TS, and Python. People who are saying Java is "playing catch up" usually compare it to languages that are doing far, far worse than Java. It's just that people who like certain features think that the language that has them is doing poorly despite them and not because of them. Many times I see people insist that other languages are "doing it right" (or better than Java) even though it is clear that the people who say this are in the minority when it comes to preferred features.

> So when people say "oh so its now got structs or value types of X", yes it has but that's because it has been stunted in its development due to big bureaucratic and hostile corporate processes, but its free now and is getting love through the OpenJDK family.

If anything, the opposite is the case. Managers love to see things ship quickly. It is our technical leadership - all people who were there in the Sun days - who insist we have to move deliberately and carefully and get things right. You can agree or disagree with the decisions, but comparing Java unfavourably to languages that are doing far worse is unconvincing.

Rather, what I think the vibe is because Java is not as popular as it was in, say, 2003. And it certainly isn't. But guess what? No other language is, either, because that time was anomalous not only for Java, but for the entire software ecosystem, which had never been as consolidated and unfragmented before or since.

To take your analogy further, not only was it thrown in the garage, but it was used to sue for billions of dollars in child support (Google) so really it had just become a cash grab.

Anyway, I wouldn't even call Java "stunted". It made choices, some reasonable, some not, and those are incredibly hard to fix later. Heck, just look at C++. Semi-compatibility with C is (IMHO) an unfixable 150 foot albatross around its neck and so many versions from C++11 onwards have simply been about making that 150 foot albatross more bearable.

I personally think treating all value classes as a single L-type in the JVM (like primitive types, basically) is a fairly neat solution to a difficult problem. But all this comes down to the original Java 2 decision to implement generics as type erasure to maintain backwards-compatibility, something that C3 NOPEd out of as a result.

Value types are a concept very far away from the "magic black box organism" school of OOP thinking. It's not a novel way of doing classic OOP (does anyone still do that?), it's a way for a language born in OOP ideology get one step further into the post-OOP world.

If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero.

It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.

the whole point of value class is that they should not encapsulate state, i.e. its a totally transparent data holder

I wanted to comment on this as well. The article mentions it but if you've never used Java in anger (is there any other way?) then readers may not understand the true implications of this because it's a breaking change, something Java rarely does. I'll explain for the non-Java people.

Java separates checking identity and equality for objects. == basically checks if two pointers are the same. Equality is a subjective concept based on an interface (ie equals/hashCode). So this means:

    new Integer(1000) == new Integer(1000) // true, used to be false
    new Integer(1000).equals(new Integer(1000)) // true
    new Integer(10) == new Long(10) // compiler error, used to false
    new Integer(10) == new Integer(10) // true

You may still be able to get the old behavior through variables too.

Anyway, if value classes lose identity then == changes from pointer equality to bitwise equality. That will hopefully resolve a bunch of corner cases like this but it is a breaking change, technically.

What did you go from to get to 21?

Mostly just hit the LTSes is what we've been doing and since about 17 it's been a pretty easy process in general.

Protip: If you ditch lombok everything gets a lot easier.

C# actually has a fair amount of gotchas and Java aims to make these explicit. So where C# mostly copied C from a low level perspeCtive, the Java guys approached this high level and analyzed in detail which constraints give you what kind of benefit.

So where in other languages, the struct/class taxonomy is binary, Java allows more granular control, reflection the semantics of the underlying domain. Snd as it turns out, structs have a wide range of footguns, especially in a parallel context.

The article has a section about that.

For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value.

I do not think you can do stack allocation in Java.

Functionally they don't - java is just catching up with (by now) ancient practice.

The false dichotomy of

> A struct in C# has identity and mutation, so the semantics of copying on assignment or passing have to be precisely defined, which gives a heavier model for the programmer and less freedom for the runtime.

Doesn't really match with what they're describing. While yes, it will not have identity in a java class ref sense, it of course will still have identity in being a unique structure in memory at a certain address. This is just splitting hairs about Java nomenclature.

As I understand it, this is anyway an extremely limited perf enhancement - for any class whose data size isn't guaranteed to be atomically writable on your CPU, after including the nullability overhead, it doesn't do anything, basically. On a CPU where 64 bits is the max guaranteed atomic read/write, even Point[] will not get optimized, since you need at least 65 bits of memory for a point value (since it has two 32 bit int fields, and it needs an extra bit to specify if it's null or not - so in practice it will take up 72 bits at the very least, possibly more with alignment requirements). But even after fixing this, if you have 3D points or if you need 64bit coordinates, your value type 3DPoints will still be individually heap allocated and your 3DPoint[] will store pointers to them, just like today, on most processors.

Given that the JVM could already do escape analysis and allocate regular classes on the stack in certain scenarios, it's very unclear what benefit, if any, this will bring for normal processors for anything except the base wrapper types - even after implementing generic support and nullability for value types in a future JVM.

Yup. That's a big disappointment they could not cram universal generics faster. But I get the problem - they have to preserve backwards compatibility. I can take 30 y.o. Java 1.0 JAR and run it on Java 27 and it will work.

Do it

You lost me at "I have a function that has a value `x`". How does function "have" a value?

That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.

I like how you point out inaccuracies and next paragraph you deliver couple more, finishing with “language wars are silly and pointless”.

What about the case of just needing one, not a collection? And when a function receives a Point, how does it know if it's a value or a reference?

Yeah, when I read that, I thought "this guy was either born wayyy after 1995, or he doesn't know the first thing about computer hardware history, or both". 1995 was the year the Pentium Pro was launched, which was (one of?) the first CPU(s) to integrate the L2 (!) cache into the same package as the CPU - they were still separate chips, but the interconnection could be made faster by putting them into the same package.

Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!

It's because the author is comparing that incident to how they were prepared with the bulk of their analysis in advance. Ready to publish as soon as it happened.

Thank you, no idea how this stuff gets upvoted here. The whole article reads like something Claude came up with.

> is it necessary for the performance boost and de-fluffing the objects?

Yes. The one part of the JVM GC that can't run concurrently is heap compaction; objects that can be moved by copying and then deleting would be a huge help for that. And it would be awkward to say the object has an identity but can't be wait/notify'd, at which point you need somewhere for the monitor to go.

> Does this happen in actuality? One would assume the allocator tries to put stuff sequentially on the heap?

Yes. Of course it tries, but semantically the pointers are just pointers and the prefetcher can guess but the system still has to chase them.

> I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective

It feels like an orthogonal objective and honestly arbitrary distinction, yes.

> Isn't this a race condition and "undefined bahvior"..? Having to limit yourself to atomic sizes seems like a huge limitation, to accomodate what is most likely buggy code.

I think they meant it like the appearance of atomic behavior from a java multithreading view.

> Does this happen in actuality?

Yes, it does happen. Having guarantees on this front leads to better performance.

> But when writing Clojure apps the JVM always reserves absurd amounts of heapspace on my machine (to my annoyance)

Might be a configuration problem?

> Is all the effort only gunna help lil toy ColorRGB examples

Arguably flattening mostly makes sense for these only.

And yeah, you are right that allocations happen on something called a thread local allocation buffer, which is basically just a pointer bump in cost and objects allocated one after the other should be physically close in memory for the most part (though an object's creation may require a bunch of other object's creation that would sit in-between). But these have headers, so not as dense as they could be (though due to GCs being generational, they may end up actually closer in the next gen? The in-between temporary objects wouldn't survive for the most part)

name another statically typed, compiled, mature language with a bunch of packages for everything and maybe I will /srs