Dupe? https://news.ycombinator.com/item?id=48590056
1 comment
Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
231–240 of 464 posts
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#232Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...
And one bit for null! So “smaller data types” means 32bits! Yay! It’s 1995 again!
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#233I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it isn't! 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. > The team, faithful to the lesson “simplify…
> a single type would have two projections: a value variant (flat, never null, behaving like a primitive) and a reference variant (a box that allows null). Across various iterations this was written as Point.val/Point.ref, and later they experimented with the Point! and Point? syntax.
This seems heavier? Having two representations and manually having to refer to .val or .ref?
You can argue that the extra flexibility lets you write safer (non-nullable) code but naively it seems more complex at the language level.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#234Earlier quoted context omitted.
Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.
This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.
But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#235Earlier quoted context omitted.
Mistyped, it's sealed interface. > So you can always have `Maybe x = null`, or even `Some x = null`. Yeah and? Practically every type system have escape hatches, like Haskell can also do side effects without the IO monad, does it make the latter useless?
The whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless. This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't h…
Since they plan to have null-restricted types, then I don't see any issue.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#236Earlier quoted context omitted.
> It came several years later, after Microsoft was legally barred That is an eloquent way of re-writing the history of Microsoft stealing Java and not being allowed to get away with it.
They didn't "steal" anything, iirc; they started as a legitimate licensee and then tried their usual embrace/extend/extinguish as "J++" (the EEE I mentioned). Sun sued for breach of license and won, barring Microsoft from extending Java outside of the (Sun-controlled) process. So they dropped it and built their own version, with blackjack and hookers.
> So they dropped it and built their own version, with blackjack and hookers.
This cracked me up
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#237It's slop o'clock
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#238Earlier quoted context omitted.
How .net got so many things right where java did not is a mystery to me, but appreciated (it has its own flaws, of course). Java, in my understanding, is still of core relevance to Oracle, and tied into a lot of contracts that require very little effort from them to maintain. But you are correct in observing that they want to be a datacentre/compute business more and more these days; they may have in fact overcomitte…
The mystery of why .NET got so many things right is simply that C# was built several years later by the exact same Microsoft engineers who had previously worked on extending Java, giving them a perfect blank slate to fix the architectural flaws they had already encountered Second mover advantage.
> giving them a perfect blank slate to fix the architectural flaws they had already encountered
and then they make everything nullable by default in c#...
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#239You could probably a whole tech thriller on the evolution on Value Types in Java. I’ve been reading the mailing lists and watched all videos on the topic and it is truly inspiring how much they managed to consolidate the design to something that always looked like java. But while also going far deeper in granularity and understanding what it even means to be a value type and what optimizations can be done where
And the only syntax change is adding 'value'.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#240I just got my projects up to JDK 21 a few months ago. Working on trying to get one upgraded to JDK 25 now and now they're talking about delivering JDK 28 in less than a year from now. How are you supposed to keep up with these rapid updates?
JDK 21 is a few years old now, so you were a few years behind. JDK 25 was released last year, which makes for the next stable LTS for a while. JDK 28 is expected in 2028, and these features are not going to be enabled by default for years after that.
Java is generally backwards compatible, so unless you're using fat frameworks that use shady internals or known-deprecated APIs, you should generally be fine immediately upgrading to the latest LTS, possibly even non-LTS versions if you have confidence in your stack.