Generics & Reification Was Code Review Request: 7157893: Warnings Cleanup in java.util.*

[Rémi Forax]

On 04/07/2012 02:35 AM, Stuart Marks wrote:
> Hi Kurchi, I think we've converged on the code changes. Please prepare 
> and post another webrev for a final cross-check before pushing.
>
> What follows is I think merely residual disagreement over the 
> philosophy of how to handle generic casts vs reification. :-)

I fully agree.

>
> On 4/6/12 3:06 AM, Rémi Forax wrote:
>> On 04/05/2012 11:04 PM, Stuart Marks wrote:
>>> I'm somewhat skeptical of making code changes now based on potential 
>>> future
>>> benefits when/if generics become reified. This was discussed before; 
>>> see
>>>
>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000454.html 
>>>
>>>
>>> In that message, John Rose said "If the best practices have to 
>>> change, then
>>> we'll have to change that code again. Or maybe the retrofit strategy 
>>> will
>>> have to take account of the existing code idioms. In any case, we'll 
>>> cross
>>> that bridge when we get to it. (Coping with reification in this case 
>>> is a
>>> decision to make tomorrow, not today.)"
>>
>> I disagree with John. The main issue with generics nowadays is that
>> most of the people doesn't care about a cast to a type variable because
>> everybody knows about erasure. So codes are written with an 
>> implementation
>> glitch in mind.
>> Frankly, I don't know if reification will appear (yes it's a kind of 
>> magical)
>> or not
>> but I think it's a sloppy path to not consider all casts as equals.
>
> In order to program effectively with generics, I think you have to 
> understand erasure and its implications. It may have been an 
> unfortunate choice, but erasure is part of the language and we have to 
> deal with it and in some cases rely on it. I don't think it's merely 
> an "implementation glitch."

Erased casts are an implementation glitch, not the erasure by itself.

>
> The difficulty I have with reification is that while there are 
> proposals floating around for how it could be done, nobody really 
> knows how it will eventually turn out, nor whether it will actually be 
> done. If it is eventually done, there will legal and illegal 
> constructs, constructs that generate warnings, and perhaps a style 
> guide for how to use reified generics properly.
>
> Right now, we can *imagine* what these future rules might be, but it 
> seems untenable to me to try to make today's code conform to those 
> imaginary future rules, especially in the absence of tools to help 
> support those rules.

There are several implementations that exist,
here is the publicly available papers.

M. Cimadamore and M. Viroli.
Reifying wildcards in Java using the EGO approach.
In SAC '07: Proceedings of the 2007 ACM symposium on
Applied computing, pages 1315{1322, New York, NY, USA,
2007. ACM.

M. Cimadamore and M. Viroli.
On Reication of Java Wildcards.
Science of Computer Programming, 2008


>
>> If unmaskNull return a V, the code of equals will upcast the value 
>> from Object
>> to V
>> to just after downcast it from V to Object,
>> I think it's better that unmask to return Object and upcast it to V 
>> when it's
>> necessary.
>
> Certainly there are cases where there's a redundant downcast and 
> upcast. In a reified world, will this be a significant expense? 
> Really, I have no idea.

I don't think so, the equivalent cast with a reified type is cheap.

>
> s'marks

Rémi