Idea how to implement VT/VO compatibility in JVM

Vitaly Davidovich vitalyd at gmail.com
Thu Jan 22 14:48:48 UTC 2015


About the "possible to do"; frankly, even if java supported this, I'd be
worried about calling such a method for the reasons I mentioned.
Inevitably, some code like that will break in very subtle ways.  I'd want
the framework I'm using to have been properly upgraded to support any T.  I
don't think backcompat should mean nobody has to do anything at all.
That's at odds with evolving the language in some cases.

sent from my phone
On Jan 22, 2015 9:34 AM, "Stéphane Épardaud" <stef at epardaud.fr> wrote:

> On 01/22/2015 03:30 PM, Vitaly Davidovich wrote:
>
>>
>> I don't quite get the elegance comment - there's already nothing elegant
>> about heavy use of reflection.  Yes, it gets the job done in some cases,
>> but it's a minority use case (I hope!).
>>
>>  Well, IMO there's a lot more elegance in List<val Date> being an
> instance of List<Object> (variance issues aside).
>
>>
>> Also, keep in mind that calling a Collection <?> taking method with value
>> type collections may not be safe as the code in that method may be relying
>> on Object semantics (e.g. locks on objects, compares reference identity,
>> etc); in some ways it's safer to call any T methods because presumably
>> person writing those is conscious of value types being a possibility and
>> also compiler may warn if any assumptions are made about it being an Object.
>>
>>  Sure, except it needs to be possible to do ;)
>


More information about the valhalla-dev mailing list