Valhalla and Improving Value Types

[jvican]

@tarsa

Not exactly related IMHO as value types as proposed for (some) next version of Java are superior to any kind of compiler tricks because of one big reason: value types can contain multiple fields, not just one.

It’s not a compiler trick, it’s a language feature.

Of course, if the JVM makes value types more efficient, that’s a win-win. But this change will make it into JDK10 (if ever makes it), which is far away. I’ll believe it when I see it.

@tarsa

Avoiding boxing is what multiple proposals of value classes are trying to achieve. I think that by creating Scala-specific solutions we are duplicating the effort.

I wouldn’t say it’s a Scala-specific solution, it’s a runtime independent solution, that will work always in all JS, JVM and native runtimes. Note that if value classes ever make it into a version of the official JVM, opaque types will benefit from them with no or little change. However, this is a belief and it’s premature to say given that I don’t know the real-world constraints and requirements that the runtime will eventually demand.

@tarsa

Another problem is that if the Scala-specific value classes machinery is different from Java’s value classes then that could probably cause confusion, interoperability problems and/ or necessity to introduce many ways of doing the same thing (which is implementing value classes).

Are you proposing to deprecate the existing value classes? Because this comment has nothing to do with opaque types.

Deprecating value classes is the vision, but it’s not clear it’s possible. Too many people use them in the wild, and without a nice migration story, I believe it’s unfeasible. In the end, I’d like this migration to happen. But which year will?

@tarsa Can you please link to an official document that says that Valhalla will be merged into JDK 10? This is a rumour that I haven’t seen confirmed. So far, I only see value types implemented as an early prototype.