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

251–260 of 464 posts

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

#251

Post by robotresearcher »

725686 wrote: post #249
dlopes7 wrote: post #182

Earlier quoted context omitted.

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

I'm tired of people jumping in to point out "AI, AI". The article is very good and informative. That is the only important thing. Geez.

No, it’s not the only important thing. The complaints about it should tell you that.

People care about provenance a lot.

Whether it’s a drawing my daughter did of her mother, a Picasso napkin sketch, a worn 1960s Stratocaster, or an blog essay, the provenance is value on top of the correctness of the item.

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

#252

Post by logicchains »

drzaiusx11 wrote: post #120

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

Surely it can't be that, it destroys basically the entire value proposition of value types, unless you use a preprocessor to write everything as SOA.

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

#254

Post by to11mtm »

PaulHoule wrote: post #119
andyjohnson0 wrote: post #12

Earlier quoted context omitted.

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

.NET made different decisions. I was at a conference on scientific programming in Java very early on that Geoff Fox put on up at Syracuse and we had a list of requests from Sun that they didn't give us but Microsoft gave many of them right away. On the other hand I really like Java's all-virtual approach to inheritance because the .NET model gives programmers more ways to screw up and get confused. Both languages sli…

I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)

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

#255

Post by einpoklum »

ericol wrote: post #196
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…

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

> I'm all in for using AI to help you write

Don't be all-in. It's important for humans to be able to write for themselves, and also to stand by what's been written in their name, which is much less likely if someone/something else has done the writing.

(proofreading is another matter though.)

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

#256

Post by pjmlp »

drdexebtjl wrote: post #246
pjmlp wrote: post #109

Earlier quoted context omitted.

Given the mess of some .NET frameworks currently, and how bad it has taken for non nullable references to be widely adopted, I don't see those correct decisions on the last releases. It is all about having AI on the framework, Aspire, multiple Web and Desktop frameworks all over the landscape. Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.

>Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either. Yeah. Even when they add new grammar nowadays, it's always just something that trivially sugars away into previous grammar (see: records, `with` clones, extension properties, required, etc). The moment they need something that it's slightly more complex... Out of scope. Even when it's completely necessary…

I have this idea, that since they went open source, but failed to gain the adoption on UNIX shops they were expecting, there are tons of features to try to make it cool again somehow.

The reality, and I can see this on my bubble, is that the .NET shops are mostly former Microsoft shops now saving Windows licenses by deploying on Linux.

Stuff like MAUI remains pretty much constrained to former Xamarin customers.

Thus minimal APIs, aspire, Blazor, and whatever comes up to support those use cases first.

There are some podcast interviews from David Fowler and Maddy Montaquila where they touch the adoption issue among newer generations.

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

#257

Post by zoogeny »

pron wrote: post #126
nixon_why69 wrote: post #102

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

I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability. As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best te…

> More generally than just Java, nullability is often a property not of a type but of a variable.

This is a tangent, but I'm not sure I follow this. Can you give an example to make this clear?

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

#258

Post by moomin »

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…

I mean, I appreciate the huge engineering and design challenges here, but C# had non-null value types in 2002. It had generic value types in 2005 and it gained not-null “types with identity” in 2019 and no-one has batted an eyelid. (Indeed the type system support for value types still includes stuff Java isn’t even considering yet.)

Saying the mental model is too hard is basically saying your userbase is stupid. This stuff is not tricky.

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

#259

Post by exidex »

drzaiusx11 wrote: post #120

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

Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though

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

#260

Post by sgt »

ericol wrote: post #196
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…

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

Exactly! But AI is here to stay. Sooner or later, even comments on HN will be 100% AI generated. And we won't be here to read them - our AI agents will. /s
Post reply on HN