Disable overrides during jdk build

[Chris Hegarty]

Thanks Joe,

The consensus seems to be to keep these warnings, and have them fixed at 
some point in the relatively near future. I'm ok with that, I've disable 
them locally for now, when trying to fix real failures, and see if I can 
address some of them over the next few weeks.

-Chris.

On 05/13/2013 08:02 PM, Joe Darcy wrote:
> 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.
>>>
>