At some point (hopefully in time for Java 10), we are likely to get Project Valhalla. When that happens, will value types gain functionality to be roughly as powerful as Java’s?
Currently, value types can only wrap a single value. As I understand it, this is primarily in order to allow their methods to be compiled into static methods on the underlying type. Additionally, having a value type extend a trait causes it to box when invoking one of the trait’s methods.
When Valhalla finally arrives:
Will value types change to be implemented as Java/JVM value types (instead of static methods)?
Will value types be allowed to have more than one value/field?
If so, will tuples become value types? All, or only smaller tuples? (because passing a Tuple20 would require copying 20 fields)
Certainly! We haven’t quite decided which Scala version will require Java
10 (assuming that’s where that part of Valhalla lands), but as soon as that
becomes clearer, we plan to make good use of all that new JVM goodness in
that Scala release. In the mean time, we’re tracking Valhalla development
and talking to the team at oracle to encourage alignment with our
requirements
We haven’t begun prototyping any of this – if anyone is interested in
investigating, let us know!
Is there any discussion regarding the fact that current value classes have the boxing/unboxing issues because (among other things) they attempt to retain OOP, while project Valhalla on the other hand happily discards this?
I’d like to read about this, because I remember reading that there was a SIP (or equivalent) for using phantom types to have “value types” that don’t box/unbox, and basically the main thing about them is that they do not retain the OOP parts.
For now, they overlap too much. I would love an opaque type alias feature, and I’ve always wondered if value classes could be broken down into something like newtype/opaque type alias and user-defined boxing/unboxing. The ship has sailed on value classes. It’ll take some time to replace them, if we come up with a full replacement in terms of smaller language features (which would be more desirable to me).
EDIT: to clarify the SIP as-is overlaps too much, but just the opaque type alias part of the SIP could be just the right size to complement VCs for users that absolutely do not want boxing, but do want newtype
There hasn’t been too much recent discussion outside this SIP. If you dig back into the mailing list archives around 2011 (when VCs were introduced, I’m sure there’s lots of interesting material.
My main concern regarding this is that Scala’s value classes will not have the same meaning as Java’s value classes, unless we change their current semantics.
Naturally, I just want Java’s value classes since I see no value in a complicated “new class concept” intended to not box but that ends up doing so when the weather conditions are not right .
Assuming I understood this correctly, java value classes don’t have identity (no equals method, and no hashcode method, no JVM lock which implies no object header, cannot be boxed into Object (because you would then have to invent an identity that it really doesn’t have)), they cannot be null (again, they are not an object) and they are not mutable, and they dont support representational polymorphism (a value class is just an aggregation of data, not an object, so it cant extend other types or be a parent type).
In my understanding, Java value types are not OOP, they are purposely cut off from the OOP chain, but generics will be augmented to allow you to abstract over normal types and value types.
C# has value types and they are wrapped into an object when you try to assign them to variable of type object. I don’t see a reason why that couldn’t work the same way in Java. Of course it very rarely would make sense to do (because we have generics so we don’t have to use raw objects and manual casts). Methods like equals and hashCode on value types are also achievable IMO.
There are specific parts that ‘confirm’ my statements:
Wrapping. Just as the eight primitive types have wrapper types that extend Object, value types should always have both an unboxed and a boxed representation. The unboxed representation should be used where practical; the boxed representation may be required for interoperability with APIs that require reference types. Unlike the existing primitive wrappers, the boxed representation should be automatically generated from the description of the value type.
Interoperability. There are a number of operations on Object that need to have a values counterpart, such as equals, hashCode, and toString. The compiler and/or VM should be free to implement these componentwise in the absence of other instruction from the value class’s author. Besides Object, other types such as Comparable should also be able to interoperate with suitable value types, opening the door to types like TreeSet. (This implies that interfaces may sometimes claim subtypes which are not also subtypes of Object.)
Why would you care for boxing, if the proposal includes extending the generics system so that the JVM can specialize the class on demand for the particular raw data type, in the video he talks about IntStream, LongStream and the like, and how hedious they are.
I was replying to you who stated that value types can’t be boxed into objects and can’t have equals and hashCode methods. That doesn’t seems to be true.
Lots of things can be done without object header. Forced immutability of value classes also allows for many optimizations at the runtime.
Also according to the mentioned article value classes can support a limited inheritance:
Can a value class implement interfaces? Yes. Boxing may occur when we treat a value as an interface instance.
Can I refactor methods into and out of value types? Yes, if you use common interfaces with default methods.
Interfaces with default methods seems roughly as powerful as universal traits that are allowed as supertypes of value types in Scala right now. So in general we don’t need to strip Scala’s value classes of functionality (to gain full compatibility) as Java ones provides everything necessary for current state of value classes in Scala.
The ability to parametrize generic classes and methods with value classes is a different topic and of course it reduces the need of explicit specialization.
Thanks for the corrections, I watched it long ago, and it seems I did get it wrong. I honestly had forgotten about the boxing part, though it seems to be focused for bridging apis like reflection. Given the intention of generics working with raw data types and value types, I’m still heavily against any form of boxing, but oh well.
Currently in Scala the built in value classes like Int and Long are represented at runtime by both raw values and boxes. The raw values are only boxed when necessary. I don’t see why you couldn’t extend that to user defined value types if Java has them. And if generics are extended to work with raw value types I guess Scala can simply reduce the amount of cases when it has to box.
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. This fact is a big selling point of value types as it would allow to have much higher control over memory layout than is now possible. Now we can have arrays of pointers to objects. With value classes we could have flat arrays of structures without any pointer indirection.
Value classes also will come with generic specialization at the JVM level, which means that we could avoid boxing much more often. 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. 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).
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.
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.
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.
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?
Quite the opposite. Existing value classes in Scala seem like a natural fit for proposed value classes in Java - we only need to lift the restriction of number of fields to reap full benefits (because Java value classes allow any number of fields, not just one).
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.
I don’t have any and Oracle is rather reserved when it comes to promises. However, JDK 9 was released just a week ago and Valhalla is in rather advanced stage, so IMO it’s too early to consider Java’s value types a far and uncertain future. Rushing to introduce new independent variations of value classes would be unwise in my view.
You can also represent the same with opaque types, in this case their underlying type would be tuples.
Sorry, I think you’re way too optimistic. There are many research projects at Oracle Labs, and out of those how many make it into the official Oracle products? Not even Graal which is in a very advanced stage has been confirmed to be an official product that will be supported and maintained by Oracle. Judging by the project’s website, Valhalla is in an early prototype. I’m quite skeptical that they will be able to make it production ready, refine it and merge it into JDK 10 within one year.
The plans are not clear. I’ll believe your claim when I see Brian Goetz or the JCP Committee confirming it.
What do you mean by independent variations of value classes?
In case it’s not clear, opaque types have clear advantages over value classes as we know them:
They can be used across different runtimes out of the box (JS and Native, notably).
They can be used as soon as this proposal makes it into scalac, if it gets accepted by the Committee.
I believe they can be adapted to Valhalla whenever this project makes it into the JVM (though as noted previously it’s premature to tell until all the technical requirements are disclosed – we’re on the same situation with value classes here).
We really do need to look carefully at the innovation on the JVM so that we don’t paint ourselves into a corner with a compiler-only solutions that have impedance mismatches with the forthcoming VM support.
VM support for Minimal Value Types is likely to arrive in a production JVM sooner than we think, perhaps even before the first long-term-support release of what is currently known as JDK9.
I would like to experiment with this feature and see if it could serve as a compilation target for Scala value classes. This would reduce complexity in our compiler, and remove the single-field restrictions. Where we find impedance mismatches, we should provide feedback to the JDK teams.
.
(see the slide