Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

jvm-weekly.com

Post reply on HN
Print view View original

181–190 of 464 posts

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#181

Post by ah1508 »

amitport wrote: post #53
rf15 wrote: post #14

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

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 as a return type in my interfaces methods to allow implementations to do non blocking I/O calls if they need.

I use Java and C# and appreciate them both.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#182

Post by dlopes7 »

mattstir wrote: post #144

> 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

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#183

Post by usrusr »

tsimionescu wrote: post #155
jstimpfle wrote: post #55

Earlier quoted context omitted.

OOP isn't just about values vs objects. Yes, the idea that everything needs identity is a big part of the problem. But another big problem is the idea that the implementation and representation of types should be hidden by default. The mindset that there isn't a known and useful data representation for a given type. That everything is done by methods parameterized by a type. It's a misguided idea. There is a place fo…

All of this would be valid, except that value classes still pretend that their fields can be private. This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.

Why pretend? "private" on value types just means nothing to see here except when you happen to be one of the functions conveniently namespaced with the struct.

But I'd say that GP's complaint about inequality leaking makes no sense anyways, because what could be more unequal than different implementation, or different internal state implying different behavior down the line? The public subset isn't some arbitrary interface that could have different implementations. And even then, "equals under interface I1" would have to be considered a very special type of "equality", not the general case.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#184

Post by cogman10 »

mattstir wrote: post #144

> 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…

> 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![]`.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#185

Post by gf000 »

Zardoz84 wrote: post #151
drzaiusx11 wrote: post #125

Earlier quoted context omitted.

I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotli…

Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.

I mean, type inference goes decades before Dlang.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#186

Post by newsoftheday »

I 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?

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#187

Post by kuhsaft »

_old_dude_ wrote: post #10
torginus wrote: post #5

I know its a faux pas in the Java world to acknowledge the existence of .NET, but how does this differ from .NET structs? Value types, generic specialization, boxing - a quick skim makes it looks like they picked the same choices.

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.

Like @layer8 said, pass by copy and pass by value are the same.

C# copies C++ behavior where you can pass a struct by value or reference, and you can mark the parameter as readonly. C# also has in/out parameters. Essentially, you can program in C# exactly like you would in C++.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

The footgun with C# structs are that you can accidentally box them onto the heap. To avoid that you can define `ref struct`s that cannot be boxed. `ref struct`s follow the C# disposable pattern.

https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#188

Post by newsoftheday »

toyg wrote: post #80
Someone wrote: post #73

Earlier quoted context omitted.

> How .net got so many things right where java did not is a mystery to me Part of the reason for that is that Java is older. https://en.wikipedia.org/wiki/C_Sharp_(programming_language)... : “In interviews and technical papers, he has stated that flaws in most major programming languages (e.g. C++, Java, Delphi, and Smalltalk) drove the fundamentals of the Common Language Runtime (CLR), which, in turn, drove the desi…

This. C# was basically always meant to be "Java but done right". It came several years later, after Microsoft was legally barred from "EEE"-ing Java and required a direct competitor.

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

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#189

Post by kuhsaft »

jaen wrote: post #132
DarkNova6 wrote: post #77

Earlier quoted context omitted.

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 ou…

Could you actually explain/exemplify any of the gotchas and what's been made better (or is this just handwaving)?

The gotcha is the potential boxing of structs onto the heap, but that can be avoided using `ref struct`s.

https://news.ycombinator.com/item?id=48599273

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#190

Post by tsimionescu »

gf000 wrote: post #180
tsimionescu wrote: post #137

Earlier quoted context omitted.

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…

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 help with at all.

Post reply on HN