Idea how to implement VT/VO compatibility in JVM

[Stephane Epardaud]

On 01/12/2015 05:05 PM, Brian Goetz wrote:
> 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.

Well, these would call the boxed methods, that would be _more_ 
compatible since they can traverse collections of value types by boxing 
them.

>
>> 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)

But there's no instantiation of "any T" that would let me not know the 
generic type at compile-time, no? Frameworks that need to traverse 
collections without having to know what type of thing they're traversing 
can't do that with value types ATM. Obviously with my proposal they'd 
box, but at least they could traverse any collection.

>
>> 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.

Well, do we have numbers on how many classes expose their state like 
this via public fields? Does the Java collection API do that? Perhaps 
you're right and it's unacceptable, but it's not really clear. I suppose 
that one way to deal with this if this was an unacceptable limitation 
would be to generate boxing specialised methods that could provide boxed 
values for virtual fields backed by actual value fields.

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

It's not about "so what" it's about the cost of the compromise. I happen 
to find that tradeoff to be much much more acceptable than treating 
List<Object> and List<@ValueType Date> disjoined. I do appreciate that 
it's a matter of personal opinion and I may be in the minority, but I've 
no evidence of that ;)