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

Rémi Forax forax at univ-mlv.fr
Wed Nov 30 09:00:40 PST 2011


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.

>
> *) 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.

>
> 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



More information about the jdk8-dev mailing list