valhalla-docs VS amber-docs

What isn't clear for me from https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/02-object-model.md is whether or not value types will indeed be headerless.

Regarding type erasure, see https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/in-defense-of-erasure.md for a justification. Note in particular that not doing erasure would have forced languages like Scala to follow Java's semantics. In cases where erasure is actually a problem, you can work around it with classes like https://fasterxml.github.io/jackson-core/javadoc/2.2.0/com/fasterxml/jackson/core/type/TypeReference.html.

Here's a (relatively recent) post on type erasure from the lead of the value types project at Oracle https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/in-defense-of-erasure.md

If you want to read something a little more formal and fleshed out, try scanning through this document, and then come back again and tell me that Brian doesn't understand your suggestion.

Source

I haven't been following it incredibly closely, but I have checked in from time to time. It's a hard problem, but there's a lot of real progress (https://github.com/openjdk/valhalla-docs/blob/main/site/desi...).

I'd wager that it will ship by the next LTS, in 2024.

Quotes from here

Record patterns are one step on the path to general pattern matching utility. The bigger building block is general deconstructors. I recommend reading Functional Transformation of Immutable Objects by Brian Goetz. The idea of "withers" shown there requires deconstructors:

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

This is the vague plan.

You may be joking but...

Here is the much more detailed version: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

This kind of pattern matching is discussed in the design notes: https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md

True, but that only pushes the question of value down the line.

I'm curious about lenses because Java did have a serious problem that required a solution: working with "simple" data correctly was difficult. The chosen solution was ADTs, so we did buy into that. But the approach being explored for transforming records (https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...) only works one level at a time rather than for an entire path. So I wonder how valuable it would be to have a solution for paths. If the answer is that it's mostly valuable for an approach we haven't bought into yet, then we might not need to consider it just yet.

Just a heads up, something like that spread operator is actually coming sooner or later to java: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Pattern matching (for records) is already a preview feature.