Probably not at the language level. If you watch the Goetz talk you linked to he answers this at 50m36s. The bytecode and JVM will be able to represent riefied generics, but at the Java language level they'll still likely maintain erasure for Object types.
Reified generics for reference types is a really, really bad idea. It solves a minor, itsy-bitsy-tiny problem, but pretty much ruins sharing of data structure among languages, because it bakes a specific variance model into the classes. For value types that's not a problem because they don't support subclassing anyway.
> For value types that's not a problem because they don't support subclassing anyway.
Could you please provide a reference for this?
Even a broad one like "a post on the Valhalla mailing list during the past summer" would be very welcome.
I'm eagerly awaiting for this feature and not being able to extend user-defined value types would be a bummer.
You'll have to search for a reference (I don't have one off hand), but obviously value types cannot possibly support subclassing. Why is that a bummer? That's how you'd want value types to behave and the only way they can[1] (without introducing explicit pointers and complex typing rules). Also, why would you ever want to subclass value types? It serves no purpose. Value types, however, will be able to implement interfaces, which, also, is exactly what you'd want.
[1]: For example, if B is a subclass of the value type A, what do you think would happen when you store a value of type B in an array of type A?
The video I linked to above talks about the restrictions (8m20s) placed on value types:
* They have no identity.
* Because they have no identity == comparisons is based on their data.
* They cannot have super classes or sub classes (they can implement interfaces though.)
* They are immutable.
* They cannot be null.
Good thing Kotlin already supports reified generics (with the current caveat that they must be used in inline functions), Java the language is less important these days than the JVM having support for the feature.
The joys of working for a company with in house developers, as long as I don't use something that would be extremely difficult to bring a new developer up to speed on (accounting for the necessity of said solution as well) I can generally make a case to use whatever.
I've got a mix of C#, Python, Kotlin and pl/pgsql code running in production right now and we've also for projects written in Node.js that are live as well. I've even got some F#!
http://www.oracle.com/technetwork/java/javase/community/jlss...