Idea how to implement VT/VO compatibility in JVM
brian.goetz at oracle.com
Mon Jan 12 16:05:06 UTC 2015
>> 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
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.)
More information about the valhalla-dev