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

281–290 of 464 posts

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

#281

Post by pron »

homebrewer wrote: post #47
tomaytotomato wrote: post #32

A lot of the comments on here are a bit unfair on what is great work being done and even more awesome work (JEPs) in the pipeline for the future. If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle) Neglected and unloved till JDK 8, its basically been playing catch up. So whe…

It was neglected during its last few years at Sun. Oracle started moving it forward at never before seen pace, while mostly maintaining backward compatibility (unlike .NET that "did things right from the start", which is what .NET Framework/.NET Core/.NET split/rewrite is according to some in this very discussion. And .NET had Java to copy and learn from, but still fucked up.) Same with MySQL, btw. "Dead" according t…

I have no idea about MySQL, but what I always remind people is that HN is more GQ/Vogue than the NYT. It focuses on novelty and aspiration more than on coverage of what the industry is actually doing. Like others, I enjoy it because it's aspirational/inspirational, but I try not to confuse it with a reflection of reality. E.g. there's little correlation between programming languages that are discussed a lot on HN and those that achieve (or don't achieve) big and long-lasting success.

In fact, much of the software industry, which writes the software that matters to our lives the most and holds most of the value delivered by software in general - the software that processes your credit-card transactions, runs your bank, sorts your mail, routes your phone calls, manages the manufacturing of your car and the shipping of your packages, holds your healthcare information, schedules and tracks your flights, and manages your law enforcement and your government - is barely represented here because the organisations that write most software aren't software companies, and they don't tend to publish technical blogs.

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

#282

Post by [deleted] »

rayiner wrote: post #264
ericol wrote: post #196

Earlier quoted context omitted.

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

You see this in all the AI generated Tik Toks. What causes AI to use such a weird construction.

[deleted]

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

#283

Post by zoogeny »

pron wrote: post #276
zoogeny wrote: post #257

Earlier quoted context omitted.

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

Yes, but it comes from Java having both runtime and compile-time types; it's harder to make the distinction in languages that don't have runtime types. In Java, you can ask, `x instanceof T` (and this is a runtime test), which means, is x one of the values in the set of values allowed by T. `null instanceof Integer` is false, even though a variable of type `Integer` can be assigned a null. So you can think of `Intege…

I think I mostly got this, but just to test it, it would be like in Typescript where I might say:

    type Foo = { x: number; }
    type Bar = { x: number; y: number }
    type FooBar = Foo | Bar;
    function baz(x: FooBar) {
      if ('y' in x) {
        // compiler now knows x is a Bar
      }
    }
In this case, the variable `x` has a property that is determined by the compiler based on control flow. i.e. it isn't explicitly carried by the type of `x`.

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

#284

Post by stickfigure »

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

I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards.

I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the language.

Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.

Declaring whole types as non-nullable is less noisy and errorprone than annotating every variable declaration. If you aren't going to give me "declare the whole codebase as non-nullable" then at least give me something coarse-grained.

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

#285

Post by mixolydianagain »

pron wrote: post #75
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…

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…

> All of the language differences between .NET and Java fall in this "non-consensus" zone

Curious if you think fibers vs async/await is still in this zone (amongst experts). It seems fibers are objectively better. But I'm no expert*

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

#286

Post by tadfisher »

Dylan16807 wrote: post #266
smokel wrote: post #209

Earlier quoted context omitted.

18446744073709551616 possible values and you can't spare 1 for null? :) TIL that Rust has NonZeroU64 which you can combine with Optional to get the required behaviour with only 64 bits per entry. [1] [1] https://doc.rust-lang.org/std/num/type.NonZeroU64.html

Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.

Java has always had this juxtaposition in language design where they don't want you to think hard about value types (hence no unsigned types), but the types themselves are precisely defined down to the specific bit pattern representation in bytecode. This is essentially hardcoded into the JVM and its bytecode specification and is too hard to change for compatibility concerns.

Luckily we have Valhalla, which is an admission that Gosling was partially wrong, and programmers who want to have an unsigned nullable non-zero 64-bit integral value type can just make one, and not have to pay outsized memory costs to do so.

If we're done paying homage to Gosling, can we get operator overloading for our fancy value types please? I have no idea if this is on the radar for Valhalla.

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

#287

Post by WD-42 »

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…

I really wanted to read this, it seems like a really interested subject. I can even forgive the AI generated images. But after a few paragraphs it became clear this was either fed through an LLM or worse.

Please, if you write a technical blog, or anything really: Stop. Stop letting the AI write for you. Nobody wants to read this.

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

#289

Post by pron »

mixolydianagain wrote: post #285
pron wrote: post #75

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

> All of the language differences between .NET and Java fall in this "non-consensus" zone Curious if you think fibers vs async/await is still in this zone (amongst experts). It seems fibers are objectively better. But I'm no expert*

I think user-mode threads are better when the language already has threads. I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.

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

#290

Post by WD-42 »

Groxx wrote: post #217
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…

I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there. Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?

I thought this was an ad bugging out. I use an adblocker. Very confusing.
Post reply on HN