Code Review Request: 7157893: Warnings Cleanup in java.util.*

[Kurchi Hazra]

Sorry, I forgot to insert a link to the webrev :
http://cr.openjdk.java.net/~khazra/7157893/webrev.02/



- Kurchi

On 4/16/2012 12:31 PM, Kurchi Hazra wrote:
>
>
> On 4/13/2012 8:26 PM, Mike Duigou wrote:
>> Looks good for commit. Just a few notes
>>
>>
>> EnumMap.java:
>>
>> maskNull seemed to have the unchecked cast well bottlenecked. Why 
>> move the cast outside of unmaskNull() and thus require 
>> @SuppressWarnings("unchecked") in many other places.
>
> I agree with this one. I have updated EnumMap.java to remove cast in 
> unmaskNull() and then remove the unrequired casts.  (and some changes 
> in 724, 740 and 789 while I was there)
>
>
> Thanks,
> Kurchi
>
>
>> Mike
>>
>>
>> On Apr 10 2012, at 16:15 , Kurchi Hazra wrote:
>>
>>> Hi Stuart,
>>>
>>>    Please find the updated webrev here: 
>>> http://cr.openjdk.java.net/~khazra/7157893/webrev.01/
>>>
>>> I hope to have included all the suggestions correctly. Also, note 
>>> that I made some new changes in Hashtable.java at lines 185, 355 and 
>>> 910 to get rid of some additional warnings.
>>>
>>> Thanks,
>>> Kurchi
>>>
>>>
>>> On 4/6/2012 5:35 PM, 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. :-)
>>>>
>>>> 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."
>>>>
>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>> s'marks
>>> -- 
>>> -Kurchi
>>>
>

-- 
-Kurchi