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

David Holmes david.holmes at oracle.com
Fri Aug 24 01:53:41 UTC 2012


Hi Dan,

On 24/08/2012 7:46 AM, 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

I'm surprised that you need this:

  426     @SuppressWarnings("fallthrough")
  ...
  436         switch (actions) {
  437             case SecurityConstants.FILE_READ_ACTION:
  438                 return READ;

If this generates a fallthrough warning then I think whatever tool 
generates that warning needs fixing!

> 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

Here:

!         @SuppressWarnings({ "unchecked", "rawtypes" })
!         Map<String,Object> result = new HashMap(properties);
!         lookup = result;

why do you keep the raw type instead of using HashMap<>(properties) ?

> 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

I'm not sure what Andrew's objection is to this change as it only 
affects how java/util/jar classes get compiled and is consistent with 
the usage in all the other Makefiles. As far as I can see you can 
override this on the make invocation anyway.

I'm unclear how this is handled in the new build.

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

As Andrew stated this is a package-private class so I don't see any issue.

Cheers,
David

> - Dan



More information about the core-libs-dev mailing list