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.
