Warnings Cleanup in java.util.<various> (more from hack day)

[John Rose]

On Dec 2, 2011, at 4:30 PM, Doug Lea wrote:

> On 12/02/11 19:16, John Rose wrote:
> 
>> Presently we are aiming at removing warnings with no changes to semantics
>> (i.e., bytecodes).
> 
> Note that this is at odds with suggestions such as:
> 
>> java/util/Currency.java --
>> 
>> The @SuppressWarnings covers the entire method. We're trying to use
>> @SuppressWarnings with as narrow a scope as possible. Sometimes it's helpful to
>> create a local variable declaration for this purpose; perhaps something like
>> this will help:
>> 
>> @SuppressedWarnings("unchecked")
>> Set<Currency> result = (Set<Currency>) available.clone();
>> return result;
> 
> This generates two more bytecodes and a local variable.
> This won't matter when the code is actually JIT-compiled, but
> the increased size might inhibit inlining or compilation.
> Surely it doesn't matter in this class, but we are very careful
> about these and many related issues in performance-sensitive
> java.util.concurrent code.

Good point; thanks.

Conflicting requirements are the spice of engineering life.

If you remove 900 warnings, there is a good chance of causing some sort of bug. ( http://blogs.oracle.com/jrose/entry/three_software_proverbs )

The 900 warnings may be masking other bugs, so we take the risk.

-- John

P.S.

> Too bad you cannot place annotations on expressions.
> 
> Also too bad that javac doesn't do trivial optimizations.

I agree.

And, too bad that our (C2) inline heuristics are so rigid.  I'm embarrassed that they count stupid stuff like unreached code (disabled asserts, throws) and data motion just as much as field and method uses.  How long have we known about this...?  The hard part about such a heuristic is that once entrenched it defends itself viciously, by taking all your benchmarks hostage.