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

Martijn Verburg martijnverburg at gmail.com
Fri Aug 24 10:19:28 UTC 2012

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 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

More information about the core-libs-dev mailing list