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

31–40 of 464 posts

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

#31

Post by usrusr »

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.

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

#32

Post by tomaytotomato »

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 when people say "oh so its now got structs or value types of X", yes it has but that's because it has been stunted in its development due to big bureaucratic and hostile corporate processes, but its free now and is getting love through the OpenJDK family.

I will continue to enjoy writing once and deploying anywhere!

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

#33

Post by gf000 »

layer8 wrote: post #21
_old_dude_ wrote: post #10

Earlier quoted context omitted.

The article has a section about that. For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value. I do not think you can do stack allocation in Java.

I don’t see a difference between pass by copy and pass by value. The mutability difference is that part of a struct can be modified in place, which value classes can’t: the value of a complete value-class variable (or array slot) can only be modified (reassigned) as a whole. This is presumably because object references to value-class objects can be created, and those objects should be immutable so their identity does…

I think that's mostly a semantic difference - Java avoided the problem of strange lifetimes, captures, tearing by fixing the semantics as immutable value objects, while C# has to deal with these issues.

But under the hood it can (and will) do a modification in place.

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

#34

Post by layer8 »

_old_dude_ wrote: post #28
layer8 wrote: post #21

Earlier quoted context omitted.

I don’t see a difference between pass by copy and pass by value. The mutability difference is that part of a struct can be modified in place, which value classes can’t: the value of a complete value-class variable (or array slot) can only be modified (reassigned) as a whole. This is presumably because object references to value-class objects can be created, and those objects should be immutable so their identity does…

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.

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

#35

Post by gf000 »

sysguest wrote: post #22
gf000 wrote: post #16

Earlier quoted context omitted.

> genuine breakthrough Well, it is - because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades. Sure, adding it to a new language is not hard. Adding it to Java which has primitives, generics and boxing, finding ways that seamlessly cover the differences between objects and primitives, while trying to plan for th…

idk maybe java should adopt something similar to rust's "edition"?

Correct me if I'm wrong, but Rust editions are a source code-level feature. So given you have the source code of newer and older rust code, you can compile them together.

That's materially distinct from Java's model of basically dynamic loading already compiled class files. Though class files do have "editions", and there are extra code to deal with different versions. But still, it should be possible to e.g. send a new value class to an old library's class that has never heard of them, and that should just work.

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

#36

Post by _kidlike »

lmm wrote: post #27
gf000 wrote: post #23

Earlier quoted context omitted.

> The stewardship of Java seems rather lacking In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times f…

> They have added proper algebraic data types to the language No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.

optional is not how algebraic data types are implemented in Java. Basically it's the combination of sealed types and records.

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

#37

Post by oddx »

rf15 wrote: post #6
torginus wrote: post #5

I know its a faux pas in the Java world to acknowledge the existence of .NET, but how does this differ from .NET structs? Value types, generic specialization, boxing - a quick skim makes it looks like they picked the same choices.

Functionally they don't - java is just catching up with (by now) ancient practice. The false dichotomy of > A struct in C# has identity and mutation, so the semantics of copying on assignment or passing have to be precisely defined, which gives a heavier model for the programmer and less freedom for the runtime. Doesn't really match with what they're describing. While yes, it will not have identity in a java class re…

> it of course will still have identity in being a unique structure in memory

No, it will not. The design allows multiple objects to share one structure in memory across multiple records, or not have such a structure at all (see Scalarization in the article).

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

#38

Post by lmm »

geokon wrote: post #13

a few questions for the pros > "The defining trait: no identity" I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective > There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent ac…

> is it necessary for the performance boost and de-fluffing the objects?

Yes. The one part of the JVM GC that can't run concurrently is heap compaction; objects that can be moved by copying and then deleting would be a huge help for that. And it would be awkward to say the object has an identity but can't be wait/notify'd, at which point you need somewhere for the monitor to go.

> Does this happen in actuality? One would assume the allocator tries to put stuff sequentially on the heap?

Yes. Of course it tries, but semantically the pointers are just pointers and the prefetcher can guess but the system still has to chase them.

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

#39

Post by gf000 »

lmm wrote: post #27
gf000 wrote: post #23

Earlier quoted context omitted.

> The stewardship of Java seems rather lacking In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times f…

> They have added proper algebraic data types to the language No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.

Sealed classes/interfaces and records are proper sum and product types.

The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java:

``` sealed class Maybe permits Some, None { record Some(T obj) {} record None() {} } ```

(You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)

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

#40

Post by Athas »

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!
Post reply on HN