Warnings Cleanup in java.util. (more from hack day) (original) (raw)

Martijn Verburg martijnverburg at gmail.com
Sat Dec 3 02:34:43 PST 2011

Hi John,

Presently we are aiming at removing warnings with no changes to semantics (i.e., bytecodes).

I'll risk stating the obvious:  If we have 900 warnings removals, and 30 of them remove warnings by changing code (to call a non-deprecated API element), and 1 of those 30 introduces a bug, we have put the 900 removals at risk, because we have made it much harder for the integrator to batch the warning changes. So let's try to keep the deprecated call and suppress the deprecation.  (There may be an exception, of course; that's when reviews help.) And (this is equally important) comment the @SuppressWarnings() with the relevant information. @SuppressWarnings("deprecation")  // String(byte[],int) in String has been deprecated // and this is actually useful because alskjdflsadkfjasl  String x = new String(new byte[0], 0);

That's definitely the conclusion I've come to as well, especially since the scope of this exercise is to remove warnings without any possible side effects. I'm going to assume that one day in the future there will be a sweep of @SuppressWarnings and this can be looked at again then.

I'll re-spin a patch and pass that through Mike (my OCA should come through soon).

Cheers, Martijn

More information about the jdk8-dev mailing list