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

[Rémi Forax]

On 11/30/2011 07:30 PM, Rémi Forax wrote:
> On 11/30/2011 06:07 PM, Maurizio Cimadamore wrote:
>> 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?
>
> String implements Comparable.
>
>>
>> Maurizio
>
> Rémi
>

Sorry, this thread should have been private.

The rules given by Maurizio are good ones.

Rémi