“plus a null flag” is going to be the GIL of the JVM.
Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
221–230 of 464 posts
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#222I 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…
Like yeah, every field is final but omg non-null is a bridge to far! Wtf?
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#223> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap. How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit repre…
The obviously used too much AI, I stopped after 2 paragraphs
The first two paragraphs are
> On June 15, Oracle engineer Lois Foltan confirmed what a good chunk of the industry had stopped believing: JEP 401: Value Classes and Objects will be integrated into the main OpenJDK repository and is targeting JDK 28.
> The change is so large that the remaining committers were asked to hold off on bigger commits during the integration. The pull request alone adds over 197 thousand lines of code across 1,816 files.
What in those paragraphs is obviously AI?
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#224I 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…
> 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 datacentr…
As someone who works with Java on a daily basis alongside a dozen other technology stacks, let me go out on a limb and say that I believe Oracle has been a stellar steward of the language. Java has been evolving quite nicely and at a reasonable pace, all without breaking the ecosystem or causing fragmentation. It certainly has its drawbacks, but doesn't everything?
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#225Earlier quoted context omitted.
Sealed classes/interfaces and records are proper sum and product types. The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java: ``` sealed class Maybe permits Some, None { record Some (T obj) {} record None() {} } ``` (You will probably have to write Maybe.Some and I might have messed up the generic synt…
Except this is completely wrong. First, a record can't extend anything, it's not even valid syntax, so a sealed class can't permit record subclasses. So no, it's not possible to create a Maybe class in Java that can only represent a Some or a None record. You could do it with regular classes, or if it's ok for Maybe to be an interface. Secondly, regardless of the sealing, nothing in any current or near future of Java…
It's probably a typo. He meant sealed interface. I think that should be quite obvious.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#226Earlier quoted context omitted.
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.
virtual thread instead of async/await is a counter example. Java is more used than C#, they can wait before delivering a new feature (given their leader position) but cannot deliver a flawed implementation that would stay in the language forever. Glad to have virtual threads and the backward compatibility that comes with it instead a Async version of sync methods + async and await keywords all over the code and Task…
C# did not ship with async/await, and Java didn't have virtual threads back then. I am specifically referring to the initial choices made in C#'s foundation.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#227I 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?
How much stuff actually broke? I feel like you can treat Java upgrades as minor upgrades most of the time, maybe you have to rebuild a few binaries but I'd be shocked if it required significant code changes.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#228Earlier quoted context omitted.
I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java. Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users. Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the…
You CAN do it, but it's much more difficult. And as far as I'm aware, both kotlin and Scala don't really suffer due to type erasure.
I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages.
That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java.
And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#229Earlier quoted context omitted.
First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions…
What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?
Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below):
An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.
While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.
Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28
#230> Will I get a fast, flat `ArrayList `? Not yet. Sad. Hope they can do this by the next LTS JDK.
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…
Which is why this is the wrong approach. Again. This is a major misstep.