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

141–150 of 464 posts

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

#141

Post by wiseowise »

inigyou wrote: post #94
jmyeet wrote: post #92

Earlier quoted context omitted.

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

How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?

How can Kotlin do it?

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

#143

Post by tsimionescu »

pron wrote: post #64
rf15 wrote: post #4

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

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

> and so Integer and int are synonymous

Except they're not, as I can do Integer x = null, but not int x = null. So an Integer is forced to occupy more memory, for very very unclear reasons. And this is also deeply weird - there is no other (mainstream?) language that allows null value types.

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

#144

Post by mattstir »

> 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 representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.

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

#145

Post by piiritaja »

nasso_dev wrote: post #66

stopped reading when i saw the AI illustration. wholly unnecessary, and it feels insulting to be fed slop like this... if you really want a fun drawing get a human artist to do it. it doesn't need to be complicated, for example https://www.code-cartoons.com/ is mostly just stick figures and does an excellent job but you don't even need any of that, a mermaid diagram would have worked perfectly fine too. instead you c…

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

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

#146

Post by scotty79 »

inigyou wrote: post #61
layer8 wrote: post #30

Earlier quoted context omitted.

There’s nothing wrong with having non-normalized representations, that’s why there is equals(). For example, you might have a value class for representing (limited-precision) fractions using two long s internally, for the numerator and denominator. For efficiency trade-off reasons, you don’t want to always shorten the fraction. But now client code can distinguish 2/3 from 4/6 using ==. Scenarios of that sort are conc…

Java can also distinguish a 2/3 object from a 4/6 object using == when they are not value types. It can even distinguish a 2/3 object from a different 2/3 object.

[dead]

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

#148

Post by jstimpfle »

rowls66 wrote: post #140
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…

There is no requirement in the Java language to use getters and setters.

But why are there so many of them?

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

#149

Post by tsimionescu »

inigyou wrote: post #94
jmyeet wrote: post #92

Earlier quoted context omitted.

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

How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?

Look at how Go did it. Any value type has a defined 0 value, and any variable of field of that type is initialized to 0 by default. So any un-initialized non-null able value type field could have the corresponding 0 value.
Post reply on HN