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