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

41–50 of 464 posts

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

#41

Post by ahartmetz »

layer8 wrote: post #30
ahartmetz wrote: post #24

Earlier quoted context omitted.

If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero. It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.

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…

Well. I'd be upset if custom operator==() for plain-old-data structs was removed from C++, but Java never had it to begin with, so for Java, it just means that you have to fall back to using traditional classes (or compare using something other than ==) if you need such "fancy" features.

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

#42

Post by layer8 »

usrusr wrote: post #31
layer8 wrote: post #15

> But careful: == looks at internal state, which isn’t always what the object represents, so for “is this the same data” comparisons keep using equals. So == for value classes will basically be like memcmp() . That is a bit unfortunate, as it breaks encapsulation, exposing implementation details. Client code can use this to do case distinctions based on how a given value is internally represented. In a way, it’s wors…

Value types are a concept very far away from the "magic black box organism" school of OOP thinking. It's not a novel way of doing classic OOP (does anyone still do that?), it's a way for a language born in OOP ideology get one step further into the post-OOP world.

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.

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

#43

Post by _kidlike »

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.

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

#44

Post by ahartmetz »

Athas wrote: post #40
ahartmetz wrote: post #19

From the article: > In 1995, a memory access cost roughly the same as a CPU operation Uhm... no?! Here's a CS paper from 1993(!) about prefetching from cache(!!) because the cache was slower than the ALU. https://www.eecs.umich.edu/techreports/cse/93/CSE-TR-152-93.... It would perhaps make Java look a little bad to say that, in 1995, the prevailing attitude in certain circles was "If it's too slow, just wait for fast…

Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!

Early 80s is also what I remember, mainly from articles about old CPUs on HN - like the zero page on the 6502 that served as a sort of L2 register file.

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

#45

Post by gf000 »

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…

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

Whether you like oracle or not, this is simply not a correct description of Java's history. It was brought up by loving parents, who due to financial problems had to put Java into a foster home where she was neglected.

But later it was adopted by new, loving parents (Oracle) and she bloomed and become a healthy and stable adult.

Like, it was Oracle that completed the open-sourcing of the platform, making OpenJDK the reference implementation. They also open-sourced the previously proprietary jfr, mission control etc tools.

They also managed to keep many of the original members of the language team, which is quite rare during these acquisitions, and Java has seen a huge improvement both on the language and runtime front.

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

#46

Post by gf000 »

layer8 wrote: post #34
_old_dude_ wrote: post #28

Earlier quoted context omitted.

I think pass by copy is a consequence of being modifiable. The other solution is to stack allocate and pass a pointer but as i said, unlike in C#, i do not think it's possible to do that in Java. In Go, you can stack allocate but when you send a pointer (that escapes), the compiler will heap allocate the object.

My point is that pass by copy and pass by value do the same thing, they copy the value representation. In other words, pass by copy means exactly pass by value.

Actually, Java only has pass-by-value, even for reference types. (The same way as C does).

People really misuse/misunderstand this term: Java objects are passed by their pointers ("references") being copied.

The alternative is pass by reference, which is done by e.g. c++, rust, who actually have references (Java doesn't). A good litmus test is whether you can write a swap method that actually changes your local variables.

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

#47

Post by homebrewer »

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 to this site, risen from the dead under Oracle for those who actually know it.

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

#48

Post by _old_dude_ »

layer8 wrote: post #34
_old_dude_ wrote: post #28

Earlier quoted context omitted.

I think pass by copy is a consequence of being modifiable. The other solution is to stack allocate and pass a pointer but as i said, unlike in C#, i do not think it's possible to do that in Java. In Go, you can stack allocate but when you send a pointer (that escapes), the compiler will heap allocate the object.

My point is that pass by copy and pass by value do the same thing, they copy the value representation. In other words, pass by copy means exactly pass by value.

For me, the difference is that if methods are inlined, the compiler is still required to do a copy for structs but not for value classes.

I do not know how this is called.

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

#49

Post by Alexander-Barth »

I think this is quite similar to julia's handling of a struct. An array of mutable structs is just an array of pointers, where every pointer directs to the underlying structure. However with an array of structs (immutable is the default), there is no such indirection. The value of all fields are stored as array element (unless you have an array of heterogeneous elements).

If you want to change an element of such an array you need to create a new immutable struct which in practice it is quite fast, but a bit verbose to write.

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

#50

Post by piokoch »

orthoxerox wrote: post #18

> Will I get a fast, flat `ArrayList `? Not yet. Sad. Hope they can do this by the next LTS JDK.

Yup. That's a big disappointment they could not cram universal generics faster. But I get the problem - they have to preserve backwards compatibility. I can take 30 y.o. Java 1.0 JAR and run it on Java 27 and it will work.
Post reply on HN