JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011

[Maurizio Cimadamore]

On 30/11/11 17:00, Rémi Forax wrote:
> On 11/30/2011 05:45 PM, Maurizio Cimadamore wrote:
>> On 30/11/11 16:33, Martijn Verburg wrote:
>>> Hi John,
>>>
>>>> Martijn,
>>>>
>>>> It is great to see this sort of enthusiasm.
>>>>
>>>> As a reviewer for similar efforts in the past, I note that it can 
>>>> help to
>>>> group changes by the amount of analysis needed for each change. For 
>>>> example,
>>>> changes to remove redundant casts are pretty easy to do, and to 
>>>> review, but
>>>> other changes might need more analysis, especially anything 
>>>> involving method
>>>> signatures.
>>> Thanks! We'll do just that - any other suggestions on how people want
>>> to receive patches/effort/results please let us know.  We really don't
>>> want to add unnecessary burden.
>> Martijn,
>> as many of the warnings out there are indeed related to generics, we 
>> need to make sure that, when fixing such warnings, we don't end up 
>> changing signatures of public API (i.e. by adding/removing 
>> generics/wildcards), as these changes are potentially harmful for JDK 
>> consumers. I think it would be best to focus on low-hanging fruits 
>> first - these are:
>>
>> *) changes that involve the body of a method (i.e. changes to the 
>> declared type of a local variable)
>>
>> *) Adding @SuppressWarnings is always safe (retention policy of this 
>> annotation is sourcefile, so that classfile won't be affected)

>
> It's a binary compatible change but it's not safe.
I was trying to sketch a list of things that can be done without 
worrying about public API-ness - in that sense adding a 
@SuppressWarnings does no harm
>
>>
>> *) changing initializer (even of public fields) is always safe - as 
>> the initializer is part of the constructor - therefore it's part of 
>> the implementation
>
> static fields initialized with a constant primitive values or strings 
> are not part of the constructor.
uhmm - which generic warnings can be issued in a static final field 
whose initializer is a primitive value/String?

Maurizio
>
>>
>> I think those rules are quite useful in distinguishing safe changes 
>> from potentially harmful changes. I would also refrain from relying 
>> on modifiers to establish whether a method is public or private API - 
>> remember that a package-private method can be overriden in a subclass 
>> and given a public modifier!
>>
>> Maurizio
>
> cheers,
> Rémi
>