Idea how to implement VT/VO compatibility in JVM

[Brian Goetz]

>> Code that is generic in T that wants to access Box<T>.t now has to
>> deal with different layouts; this is a pretty big change to our
>> compilation story (with consequences for performance.)
>
> Is this really true? I thought that because there's no instantiation of the
> any type, every any-generic method has to be specialised anyways, so there
> isn't really generic code that abstracts over both Object-generic and
> value-generic.

Part of what you may be missing is: code that was compiled with older 
compilers.  While we have the opportunity to change the translation of 
newly compiled code, there will be existing code out there that we also 
need to be compatible with.

> To me the compromise that we can't write code that iterates say, a
> list, without knowing at compile-time what type of value-generics it may
> hold is a compromise that will haunt Java forever.

This is just incorrect.  You can write a generic method:

   <any T> forEach(Collection<T> c, Consumer<T> action)

> This clearly doesn't work with fields, but so what? Add a language limitation that
> fields of Any-generic types must be private.

Which means that any class that had public fields can't ever be anyfied. 
  Also, as people become more aware of the evils of mutability, more 
people are (correctly) writing classes with public final fields rather 
than intermediating with unnecessary getters.

(Hint: when you're inclined to say "but so what", that's the warning 
sign that you're spiraling off into wishful-thinking territory.)