Idea how to implement VT/VO compatibility in JVM

[Maurizio Cimadamore]

Thanks, there are some useful thoughts in here, we're still thinking 
about directions.

To some extent, this whole specialization business is like a knob - on 
one end of it there's a 'performance' label, on the opposite end there's 
a 'language uniformity' label. I think it's fair to point out (as you 
and others have done) that the current proposal has the knob turned all 
the way up to the performance end (which was kinda the point!) and that 
if, somehow the knob was turned back a little, a slightly different 
compromise could be achieved. Does different means better? Jury's still 
out :-)

Maurizio

On 12/01/15 16:30, Stephane Epardaud wrote:
> 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 ;)