Would be nice to see this in Java 9 or even sooner.
There is no way that they will ship this for pre Java 9.
An issue with the Java 9 proposal seems that value types are 'final' (makes sense), so to use them as structs, the compiler (javac) will do boxing/unboxing like with primitives (since java 5).
value types are "persistent" like Strings or Java 8 date/time types. By "use them as structs", you want traditional field modification. Why? Can't you just write your class like any other persistent class? I don't see where you think Java would do boxing on value types.
I'm not confident it will be usable for games - yet.
I guarantee you that these will be usable for games. Point, vector, matrix would all use this. So would general purpose tuple types. An Optional value type would be useful as well.
The problem with the current proposal seems to be that you can't have pointers/references to value types.
One of the main uses of value types might be in developing complex memory-efficient structures, which is going to need some way to do "pointers to structs"
The main purpose of this whole concept is the efficiency you gain by not having a pointer. For the scenarios where you really need pointers, keep using regular class.
The JVM doesn't allow direct pointers/references to primitives like ints and floats without workarounds. That doesn't seem to be a problem.
Data structures like linked lists require recursive references and fundamentally could not use this value type construct.
has anyone else given it a fine examination?
This looks like C# structs with the big difference being the mandatory requirement of (immutable) persistence.
The official Microsoft guidelines for choosing between classes vs structs (http://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx
) says only use a struct when:
- It logically represents a single value, similar to primitive types (int, double, etc.).
- It has an instance size under 16 bytes.
- It is immutable.
- It will not have to be boxed frequently.
Microsoft recommends you only use structs with immutable values, but the language doesn't require it. This Java proposal requires persistent immutability. The downside of having large structs is that pass-by-value copy operations become expensive. When the runtime has a guarantee of immutability, it can internally pass by reference instead.
Persistent data structures are inherently thread safe and logically easy to work with, but I don't see what other advantage that requirement provides. There must be some advantage or the Java proposal wouldn't require it, but I don't see what that is.
Even the relatively new tuple classes introduced in C# 4.5 uses regular classes, not structs, just like you would do in current versions of Java. I wonder why?
Also, even third party "Option" types in C# all seem to use classes, not structs. And Scala with its limited value type support, doesn't use value types for Option and implements Option as a regular class.