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.
