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

151–160 of 464 posts

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

#151

Post by Zardoz84 »

drzaiusx11 wrote: post #125
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…

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.

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

#152

Post by Zardoz84 »

cm2187 wrote: post #88
toyg wrote: post #80

Earlier quoted context omitted.

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.

But what I don’t get reading the original article is that they present how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.

Dlang this this before. You have classes and struts, with different semantics.

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

#154

Post by pron »

tsimionescu wrote: post #143
pron wrote: post #64

Earlier quoted context omitted.

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

That's not quite how it works in Valhalla. Because Integer and int already exists, your declarations above will be interpreted with those meanings, but (assuming some TBD nullability annotation), they will be equivalent to `int? x` and `Integer! x` respectively. In other words, the nullability of a variable is a separate concern from the data type, and other than the different defaults on variable declarations (as these types already exist), Integer and int become the same type.

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

#155

Post by tsimionescu »

jstimpfle wrote: post #55
layer8 wrote: post #42

Earlier quoted context omitted.

That’s just not true, you can have a completely value-based language without OOP that still doesn’t leak implementation details of the values, while also supporting UDTs.

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.

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

#156

Post by mattstir »

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

That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.

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

#157

Post by tsimionescu »

papercrane wrote: post #135
jmyeet wrote: post #108

Earlier quoted context omitted.

I wanted to comment on this as well. The article mentions it but if you've never used Java in anger (is there any other way?) then readers may not understand the true implications of this because it's a breaking change, something Java rarely does. I'll explain for the non-Java people. Java separates checking identity and equality for objects. == basically checks if two pointers are the same. Equality is a subjective…

new Integer(10) == new Integer(10) // true Before value classes this would always be false. The only time comparing Integer objects with == could be true is if Integer object was create by going through Integer.valueOf (or obviously if they were the same object reference.) By default the cached values where -127 to 127, but that is tuneable at runtime. https://github.com/openjdk/jdk/blob/jdk-27%2B27/src/java.bas...

It could also be true if the instances were created through auto-boxing (e.g. arrayList.add(10); arrayList.add(10); arrayList.get(0) == array List.get(1) //would return true, but false if you used 1000 instead of 10).

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

#158

Post by fsuts »

recursive-call wrote: post #105
fsuts wrote: post #101

Java = Oracle = Ellisons way of doing business Unless your company forces you to use Java for new projects, consider a change

name another statically typed, compiled, mature language with a bunch of packages for everything and maybe I will /srs

Rust

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

#159

Post by mike_hearn »

tsimionescu wrote: post #143
pron wrote: post #64

Earlier quoted context omitted.

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

It's not that weird. The goal is to enable existing types to be turned into value types without porting the users, so stdlibs and other libraries can mark types as value types without an API break.

That goal is an ideal and can't be reached perfectly. Converting a type to a value type will break clients that synchronize on them, or rely on identity for some reason. But such cases are rare, and can be weighed up on an individual basis when making the decision about whether to do it. Storing things in a nullable variable on the other hand is very common and changing the rules to prevent it would make every such change a source incompatible breaking change.

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

#160

Post by mike_hearn »

wiseowise wrote: post #141
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?

How can Kotlin do it?

A lot of the language rules are required to make its approach to nullability work. Hence odd keywords like "lateinit var".
Post reply on HN