Disable overrides during jdk build

[Joe Darcy]

Failure to have proper equals / hashCode behaviors can create hard to 
discover bugs if such objects are ever put in collections.

By default, I would categorize these as real problems to be fixed and 
for a @SuppressWarning annotation to be wrong approach to resolve the 
warning.

Since its initial implementation, the javac warning generation has been 
tuned to be smarter; it only reports a problem if hashCode isn't 
overridden anywhere in the superclass chain. (It is often possible to 
have more sharing among hashCode implementation than among equals 
implementations.)

Regards,

-Joe

On 5/13/2013 8:36 AM, Chris Hegarty wrote:
> I have no objection to someone fixing these warnings. They are across 
> a number of different areas, and could take an amount of time to resolve.
>
> If we are to have a concerted effort, I'm not sure that I would start 
> with these warnings. I too feel the pain, and it does appear that we 
> are moving backwards on this problem, I just don't see that this is 
> the right place to start.
>
> I'm just after a slightly easier life here, but I understand that this 
> is a hot topic ;-)
>
> -Chris.
>
> On 13/05/2013 16:08, Alan Bateman wrote:
>>
>> No objection although it feels like we are going backwards rather than
>> forwards.
>>
>> I submitted a few bugs on this topic recently as it seems to me that
>> there aren't too many override warnings to kill off. Daniel Fuchs has a
>> patch out for review today that fixes these warnings in the jaxp
>> repository. The overrides warnings were also fixed in the jaxws
>> repository as part of the bulk update a few weeks ago. That leaves 12
>> for the corba repository and about 29 in the jdk repository (29 on Linux
>> at least, it varies by platform).
>>
>> I completely agree with you that the noise is high. On several occasions
>> I've had to edit the build log to find the errors when they get lots in
>> the warnings. I just wonder whether we should just fix what seems like a
>> small number of warnings.
>>
>> -Alan
>>
>>
>> On 13/05/2013 14:53, Chris Hegarty wrote:
>>> Please hold your fire! This is not a suggestion to about general
>>> handling of warnings during the build, just a specific gripe I have
>>> when trying to find genuine build failures among the noise.
>>>
>>> Would there be any objection to adding '-overrides' to the jdk build?
>>>
>>> This lint warning was added after the new build was introduced. I
>>> suspect it would have been suppressed originally if it was supported
>>> at the time.
>>>
>>> diff --git a/makefiles/Setup.gmk b/makefiles/Setup.gmk
>>> --- a/makefiles/Setup.gmk
>>> +++ b/makefiles/Setup.gmk
>>> @@ -23,7 +23,7 @@
>>> # questions.
>>> #
>>>
>>> -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally 
>>>
>>>
>>> +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-overrides 
>>>
>>>
>>>
>>> # The generate old bytecode javac setup uses the new compiler to
>>> compile for the
>>> # boot jdk to generate tools that need to be run with the boot jdk.
>>>
>>> -Chris.
>>>
>>> P.S. how to handle warnings generally will have to be addressed at
>>> some point, but I am not making any proposal at this time.
>>