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
