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

121–130 of 464 posts

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

#121

Post by tsimionescu »

nixon_why69 wrote: post #102
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…

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.

This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.

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

#122

Post by drzaiusx11 »

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…

They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.

That said, we've been gnawing on this limb for a while...

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

#123

Post by ahoka »

gf000 wrote: post #72
ahoka wrote: post #70

Earlier quoted context omitted.

Or just do as Kotlin and embrace null, but in a type aafe way.

"Funnily", having nullable types be practically `T | Null` gives you union types, not sum types (the latter is, importantly are a disjunct union!) The main difference is that (T | Null) | Null = T | Null, while Maybe > is different from Maybe

Your point being?

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

#124

Post by rf15 »

_kidlike wrote: post #43
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…

so your complaint is about the blogger, not the Java language? also, null markers are coming too: https://openjdk.org/jeps/8303099 Its just that they have to deliver things incrementally. This PR that introduces value classes/objects is already 200k lines long.

I agree, but I have seen the previous proposals/jeps and the discourse around them is rather discouraging. I hope this one can find it's way out of Draft, but I'll only believe it when I see it.

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

#125

Post by drzaiusx11 »

andyjohnson0 wrote: post #12
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…

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

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 kotlin, project loom event loop like nodes, etc.

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

#126

Post by pron »

nixon_why69 wrote: post #102
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…

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 technical in-memory representation for each use. For example, the compiler could choose not to flatten variables that could be null in the heap but to flatten them in the stack. That's the general idea, but I'm not sure about the details, some of which may yet change.

More generally than just Java, nullability is often a property not of a type but of a variable. For example, in C, an int may not be null, but a pointer to an int may be. Now, in C, `int` and `int*` are two different types, but that's exactly a distinction that the original projection-spit design made and we wanted to avoid. But you could still end up with a variable that could hold either an integer or a null and another that may hold an integer but not a null, only this is separate from the reference/value projection, which combines both identity and nullability (in C, `int*` is not only nullable, but also has identity).

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

#127

Post by inigyou »

jmyeet wrote: post #98
inigyou wrote: post #94

Earlier quoted context omitted.

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?

The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List . The list itself couldn't be null unless it was ?List . Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no…

you seem to have ignored the question and answered a completely different one

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

#128

Post by pjmlp »

cm2187 wrote: post #118
pjmlp wrote: post #113

Earlier quoted context omitted.

The problem is how to do it without breaking ABI, 30 years of Maven Central is very relevant, Java isn't doing a Python over value types.

But if you define a new type, how is that breaking backward compatibility?

Because that is missing the point.

All the types that are value types in semantics, e.g. Optional, should be proper value types on Valhalla.

Additionally, they should be compatible with existing code that expects them as parameters, fields,.... without being recompiled from source.

If it is a complete new type without backwards compatibility, no one is going to adopt it, other than a few niche cases.

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

#129

Post by jaen »

ivolimmen wrote: post #100
watwut wrote: post #17

Earlier quoted context omitted.

> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully…

> -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure).

How do you expect this to work then? If the provider is bad, blaming LINQ for it makes no sense...

You either have a high level of abstraction and possible performance pitfalls - or a low level of abstraction, and also performance pitfalls since the code is less modular, more coupled and harder to read.

LINQ can in many cases improve performance significantly in large applications when used properly, since it avoids N+1 query problems due to implementation hiding/modularity, and allows composing parts of queries across different vertical subsystems of the application (vs. each subsystem doing its own query and then joining them with more boilerplate).

Nothing in Java compares to this. jOOQ and Hibernate (and the rest in the ORM ecosystem) are pale shadows, exactly due to lacking language features (such as reified expression trees), and even then, they only work with databases.

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

#130

Post by peterashford »

watwut wrote: post #17
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…

> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

Yeah, me too. Java always seemed to consider design a lot more than C# which seems to have taken more of a kitchen sink approach to language design. That stuff piles up over time (see c++)
Post reply on HN