JDK 8 Warnings Cleanup Day -- Dec. 1st, 2011
maurizio.cimadamore at oracle.com
Wed Nov 30 09:07:43 PST 2011
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,
>>>> 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
>>>> changes to remove redundant casts are pretty easy to do, and to
>>>> review, but
>>>> other changes might need more analysis, especially anything
>>>> involving method
>>> 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.
>> 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?
>> 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!
More information about the jdk8-dev