Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

Ulf Zibis Ulf.Zibis at CoSoCo.de
Fri Aug 31 10:19:11 UTC 2012


Stuart, much thanks for your detailed explanation. The as is situation has not been in question from 
my side, but anyway it seems, that it had catalysed a new solution, despite that the additional 
break; could affect JIT optimization of the enclosing loop. So there should be an explaining 
comment, even if Hotspot (but maybe others) is not affected in current configuration.

Am 31.08.2012 03:45, schrieb Stuart Marks:
> On 8/30/12 7:14 AM, Ulf Zibis wrote:
>> I can see that it is reasonable/possible to bind a
>> @SuppressWarnings("unchecked") to a declaration which contains the unchecked
>> assignment, but which declaration should contain a fallthrough case?

... You may call me pedantic, but the above question is still open to me.


> It turns out that this discussion is moot, as the switch fall-through is actually unnecessary! The 
> comma case falls through to the next case, but all that does is break. The warning can be 
> eliminated simply by replacing /*FALLTHROUGH*/ with a break statement. This removes the need for 
> the SuppressWarnings annotation.

Maybe one could optimize javac to recognize such situation and hold back the warning in that case, 
as the current code looks more intuitive and has potential advantage for JIT optimization.

>
> This permissions-parsing code occurs in several places around the JDK, .....
> [...]
> Obviously it would be nicer to unify the five copies into one, but this is a much bigger change 
> that I think is clearly out of scope.

Is there already a bug report about that or do you consider to post one?

-Ulf




More information about the core-libs-dev mailing list