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

[Martijn Verburg]

Hi all,

> On 08/23/2012 11:46 PM, Dan Xu wrote:
>>
>> Please review the fix of CR 7193406 at
>> http://cr.openjdk.java.net/~dxu/7193406/webrev/.
>>
>> It cleans up warnings in the following java files.
>>
>>    src/share/classes/java/io/FilePermission.java
>>    src/share/classes/java/util/ArrayDeque.java
>>    src/share/classes/java/util/Arrays.java
>>    src/share/classes/java/util/Collections.java
>>    src/share/classes/java/util/HashMap.java
>>    src/share/classes/java/util/JumboEnumSet.java
>>    src/share/classes/java/util/PriorityQueue.java
>>    src/share/classes/java/util/PropertyResourceBundle.java
>>    src/share/classes/java/util/jar/JarVerifier.java
>>    src/share/classes/java/util/jar/Pack200.java
>>    src/share/classes/sun/util/PreHashedMap.java
>>
>>
>>
>> And it enables fatal warning flag in the following make file.
>>
>>    make/java/jar/Makefile
>>
>>
>> In FilePermission.java file, I make one change to its method signature,
>>
>>    public Enumeration elements()  ==> public Enumeration<Permission>
>>    elements()
>>
>>
>> I am not sure whether it will cause an issue of backward compatibility.
>> Please advise. Thanks!
>>
>> - Dan
>
>
> Hi Dan,
> I'm not sure to like the fact that you introduce some local variables just
> to get ride of some warnings given that Hotspot compilers are sometimes
> sensitive to that.
> I think this practice should be discussed on this list before committing
> this changeset.
>
> so is it a good idea to add a temporary local variable to fix a generics
> warning or should @SuppressWarnings should be set on the whole method ?
>
> Rémi

Is it worth analysing the byte code to see the potential impact of
this extra local
variable?  We did that for a bunch of the javac warnings cleanup in London and
had a defacto rule of 'no byte code changes' or if there was one we'd get a few
Hotspot enthusiasts to analyse it.

Cheers,
Martijn