Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Thu Jul 28 13:27:44 PDT 2011


On 07/28/11 07:12 PM, Alexandre Boulgakov wrote:

It seems strange that javac didn't emit a "raw types" warning on the raw Iterator. Do you know if that is by design, or is it a bug?

I'm not sure why javac didn't generate a warning for this. I only noticed it because providers is private and I wondered where it was being called.

It may be worth trying to create a simple testcase that demonstrates this and send it to compiler-dev, but it shouldn't prevent this work from progressing.

-Chris.

-Sasha

On 7/28/2011 2:27 AM, Chris Hegarty wrote: Hi Sasha,

Thanks for cleaning up these warnings. I reviewed all the changes, paying particular attention to SCTP, and I'm happy with them. One minor comment, for Charset.java Since providers() now returns a Iterator, the callers of this method could also be updated to use the generified type and remove (what would be) a redundant cast. Thanks, -Chris. On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: Hello everyone,

Please review these NIO changes. Bug detail: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7068616 <http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7068616> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ Most of the changes are one-line fixes to remove warnings, and I've updated the make files to flag warnings as errors from now on, ignoring deprecation warnings in sun.io.*. I also revised some of the try-catch blocks to make use of multicatch syntax. There are two larger changes in src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I changed a private inner class from "private class InternalNotificationHandler extends AbstractNotificationHandler" to "private class InternalNotificationHandler extends AbstractNotificationHandler" because it was not using the type variable T. AbstractNotificationHandler is consistent with the original behavior where InternalNotificationHandler was used as a raw type. Thanks, Sasha



More information about the nio-dev mailing list