Re: RFR: 8003380 - Compiler warnings in logging test code
and pushed...
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b829a5a46ee
-Chris.
On 11/28/2012 06:51 PM, Jim Gish wrote:
Since we don't yet have a resolution on this, I modified the test code
in question to remove the @SuppressWarnings(unused) and actually
removed the unused references (and retested, of course).
Please review
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
and if ok, Chris, could you please go ahead and push the changes?
thanks,
Jim
On 11/28/2012 01:27 PM, Jim Gish wrote:
Here's the list of @suppresswarnings values that are recognized by
Eclipse Juno:
Excluding warnings using @SuppressWarnings
Since Java 5.0, you can disable compilation warnings relative to a
subset of a compilation unit using
the|java.lang.SuppressWarning|annotation.
@SuppressWarning(unused) public void foo() {
String s;
}
Without the annotation, the compiler would complain that the local
variable|s|is never used. With the annotation, the compiler silently
ignores this warning locally to the|foo|method. This enables to keep
the warnings in other locations of the same compilation unit or the
same project.
The list of tokens that can be used inside
a|SuppressWarnings|annotation is:
* allto suppress all warnings
* boxingto suppress warnings relative to boxing/unboxing operations
* castto suppress warnings relative to cast operations
* dep-annto suppress warnings relative to deprecated annotation
* deprecationto suppress warnings relative to deprecation
* fallthroughto suppress warnings relative to missing breaks in switch
statements
* finallyto suppress warnings relative to finally block that don't
return
* hidingto suppress warnings relative to locals that hide variable
* incomplete-switchto suppress warnings relative to missing entries in
a switch statement (enum case)
* javadocto suppress warnings relative to javadoc warnings
* nlsto suppress warnings relative to non-nls string literals
* nullto suppress warnings relative to null analysis
* rawtypesto suppress warnings relative to usage of raw types
* resourceto suppress warnings relative to usage of resources of type
Closeable
* restrictionto suppress warnings relative to usage of discouraged or
forbidden references
* serialto suppress warnings relative to missing serialVersionUID
field for a serializable class
* static-accessto suppress warnings relative to incorrect static access
* static-methodto suppress warnings relative to methods that could be
declared as static
* superto suppress warnings relative to overriding a method without
super invocations
* synthetic-accessto suppress warnings relative to unoptimized access
from inner classes
* sync-overrideto suppress warnings because of missing synchronize
when overriding a synchronized method
* uncheckedto suppress warnings relative to unchecked operations
* unqualified-field-accessto suppress warnings relative to field
access unqualified
* unusedto suppress warnings relative to unused code and dead code
(From
http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm)
Jim
On 11/16/2012 10:02 PM, Stuart Marks wrote:
On 11/16/12 6:39 PM, Stuart Marks wrote:
The background is that the words that can be supplied to
@SuppressWarnings
reside in an uncontrolled namespace. The JLS [1] defines only
unchecked and
any others are compiler-specific. The set of words accepted here by
javac is
the same as the words defined for -Xlint.
[1]
http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Whoops, the JLS defines deprecation as well (as Alan pointed out in
another thread the other day). But the rest of the point stands.
s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
Since we don't yet have a resolution on this, I modified the test code
in question to remove the @SuppressWarnings(unused) and actually
removed the unused references (and retested, of course).
Please review
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
and if ok, Chris, could you please go ahead and push the changes?
thanks,
Jim
On 11/28/2012 01:27 PM, Jim Gish wrote:
Here's the list of @suppresswarnings values that are recognized by
Eclipse Juno:
Excluding warnings using @SuppressWarnings
Since Java 5.0, you can disable compilation warnings relative to a
subset of a compilation unit using
the|java.lang.SuppressWarning|annotation.
@SuppressWarning(unused) public void foo() {
String s;
}
Without the annotation, the compiler would complain that the local
variable|s|is never used. With the annotation, the compiler silently
ignores this warning locally to the|foo|method. This enables to keep
the warnings in other locations of the same compilation unit or the
same project.
The list of tokens that can be used inside
a|SuppressWarnings|annotation is:
* allto suppress all warnings
* boxingto suppress warnings relative to boxing/unboxing operations
* castto suppress warnings relative to cast operations
* dep-annto suppress warnings relative to deprecated annotation
* deprecationto suppress warnings relative to deprecation
* fallthroughto suppress warnings relative to missing breaks in switch
statements
* finallyto suppress warnings relative to finally block that don't
return
* hidingto suppress warnings relative to locals that hide variable
* incomplete-switchto suppress warnings relative to missing entries in
a switch statement (enum case)
* javadocto suppress warnings relative to javadoc warnings
* nlsto suppress warnings relative to non-nls string literals
* nullto suppress warnings relative to null analysis
* rawtypesto suppress warnings relative to usage of raw types
* resourceto suppress warnings relative to usage of resources of type
Closeable
* restrictionto suppress warnings relative to usage of discouraged or
forbidden references
* serialto suppress warnings relative to missing serialVersionUID
field for a serializable class
* static-accessto suppress warnings relative to incorrect static access
* static-methodto suppress warnings relative to methods that could be
declared as static
* superto suppress warnings relative to overriding a method without
super invocations
* synthetic-accessto suppress warnings relative to unoptimized access
from inner classes
* sync-overrideto suppress warnings because of missing synchronize
when overriding a synchronized method
* uncheckedto suppress warnings relative to unchecked operations
* unqualified-field-accessto suppress warnings relative to field
access unqualified
* unusedto suppress warnings relative to unused code and dead code
(From
http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm)
Jim
On 11/16/2012 10:02 PM, Stuart Marks wrote:
On 11/16/12 6:39 PM, Stuart Marks wrote:
The background is that the words that can be supplied to
@SuppressWarnings
reside in an uncontrolled namespace. The JLS [1] defines only
unchecked and
any others are compiler-specific. The set of words accepted here by
javac is
the same as the words defined for -Xlint.
[1]
http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Whoops, the JLS defines deprecation as well (as Alan pointed out in
another thread the other day). But the rest of the point stands.
s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
I'm a bit happier that @SuppressWarnings(unused) has been removed.
Note, I only got pulled into this because of the @SuppressWarnings namespace
question; I didn't look at the rest of the webrev.
s'marks
On 11/28/12 10:51 AM, Jim Gish wrote:
Since we don't yet have a resolution on this, I modified the test code in
question to remove the @SuppressWarnings(unused) and actually removed the
unused references (and retested, of course).
Please review
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ and if
ok, Chris, could you please go ahead and push the changes?
thanks,
Jim
On 11/28/2012 01:27 PM, Jim Gish wrote:
Here's the list of @suppresswarnings values that are recognized by Eclipse Juno:
Excluding warnings using @SuppressWarnings
Since Java 5.0, you can disable compilation warnings relative to a subset of
a compilation unit using the|java.lang.SuppressWarning|annotation.
@SuppressWarning(unused) public void foo() {
String s;
}
Without the annotation, the compiler would complain that the local
variable|s|is never used. With the annotation, the compiler silently ignores
this warning locally to the|foo|method. This enables to keep the warnings in
other locations of the same compilation unit or the same project.
The list of tokens that can be used inside a|SuppressWarnings|annotation is:
* allto suppress all warnings
* boxingto suppress warnings relative to boxing/unboxing operations
* castto suppress warnings relative to cast operations
* dep-annto suppress warnings relative to deprecated annotation
* deprecationto suppress warnings relative to deprecation
* fallthroughto suppress warnings relative to missing breaks in switch
statements
* finallyto suppress warnings relative to finally block that don't return
* hidingto suppress warnings relative to locals that hide variable
* incomplete-switchto suppress warnings relative to missing entries in
a switch statement (enum case)
* javadocto suppress warnings relative to javadoc warnings
* nlsto suppress warnings relative to non-nls string literals
* nullto suppress warnings relative to null analysis
* rawtypesto suppress warnings relative to usage of raw types
* resourceto suppress warnings relative to usage of resources of type
Closeable
* restrictionto suppress warnings relative to usage of discouraged or
forbidden references
* serialto suppress warnings relative to missing serialVersionUID
field for a serializable class
* static-accessto suppress warnings relative to incorrect static access
* static-methodto suppress warnings relative to methods that could be
declared as static
* superto suppress warnings relative to overriding a method without
super invocations
* synthetic-accessto suppress warnings relative to unoptimized access
from inner classes
* sync-overrideto suppress warnings because of missing synchronize
when overriding a synchronized method
* uncheckedto suppress warnings relative to unchecked operations
* unqualified-field-accessto suppress warnings relative to field
access unqualified
* unusedto suppress warnings relative to unused code and dead code
(From
http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm)
Jim
On 11/16/2012 10:02 PM, Stuart Marks wrote:
On 11/16/12 6:39 PM, Stuart Marks wrote:
The background is that the words that can be supplied to @SuppressWarnings
reside in an uncontrolled namespace. The JLS [1] defines only unchecked and
any others are compiler-specific. The set of words accepted here by javac is
the same as the words defined for -Xlint.
[1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Whoops, the JLS defines deprecation as well (as Alan pointed out in
another thread the other day). But the rest of the point stands.
s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
On 11/15/12 3:06 AM, Alan Bateman wrote: On 14/11/2012 22:44, Chris Hegarty wrote: - @SuppressWarnings(unused) Eclipse??? Do we have precedent for adding these suppressions?? I don't see it in the -Xlint options that javac supports so it might be specific to ECJ. I recall this topic came up during one of the warnings clean-up days, Stuart might remember the outcome. Yes, I gave an (Oracle internal) tech talk on warnings cleanup some time back where I mentioned this issue. I'll repeat the results here for everybody's benefit. The background is that the words that can be supplied to @SuppressWarnings reside in an uncontrolled namespace. The JLS [1] defines only unchecked and any others are compiler-specific. The set of words accepted here by javac is the same as the words defined for -Xlint. I did a survey of the sources in the jdk repo and found that the javac-defined warnings suppression tags were: deprecation fallthrough rawtypes serial try unchecked In addition, I found the following non-javac tags used: all empty-statement unused LeakingThisInConstructor OverridableMethodCallInConstructor ResultOfObjectAllocationIgnored SleepWhileHoldingLock UnnecessaryLocalVariable I actually have no idea which tool processes these. The names are suggestive though. I don't think we ever determined any policy about which names ought to be used in the OpenJDK code base. At the very least I think any of the javac -Xlint words is acceptable. I could be convinced that allowing others is a good idea (such as the Eclipse ones) if they're useful and a definition is available somewhere. s'marks [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Re: RFR: 8003380 - Compiler warnings in logging test code
On 11/16/12 6:39 PM, Stuart Marks wrote: The background is that the words that can be supplied to @SuppressWarnings reside in an uncontrolled namespace. The JLS [1] defines only unchecked and any others are compiler-specific. The set of words accepted here by javac is the same as the words defined for -Xlint. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 Whoops, the JLS defines deprecation as well (as Alan pointed out in another thread the other day). But the rest of the point stands. s'marks
Re: RFR: 8003380 - Compiler warnings in logging test code
Some of these are actually supported by NetBeans, such as: LeakingThisInConstructor Regards, Michael On Sat, Nov 17, 2012 at 12:39 AM, Stuart Marks stuart.ma...@oracle.com wrote: On 11/15/12 3:06 AM, Alan Bateman wrote: On 14/11/2012 22:44, Chris Hegarty wrote: - @SuppressWarnings(unused) Eclipse??? Do we have precedent for adding these suppressions?? I don't see it in the -Xlint options that javac supports so it might be specific to ECJ. I recall this topic came up during one of the warnings clean-up days, Stuart might remember the outcome. Yes, I gave an (Oracle internal) tech talk on warnings cleanup some time back where I mentioned this issue. I'll repeat the results here for everybody's benefit. The background is that the words that can be supplied to @SuppressWarnings reside in an uncontrolled namespace. The JLS [1] defines only unchecked and any others are compiler-specific. The set of words accepted here by javac is the same as the words defined for -Xlint. I did a survey of the sources in the jdk repo and found that the javac-defined warnings suppression tags were: deprecation fallthrough rawtypes serial try unchecked In addition, I found the following non-javac tags used: all empty-statement unused LeakingThisInConstructor OverridableMethodCallInConstructor ResultOfObjectAllocationIgnored SleepWhileHoldingLock UnnecessaryLocalVariable I actually have no idea which tool processes these. The names are suggestive though. I don't think we ever determined any policy about which names ought to be used in the OpenJDK code base. At the very least I think any of the javac -Xlint words is acceptable. I could be convinced that allowing others is a good idea (such as the Eclipse ones) if they're useful and a definition is available somewhere. s'marks [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Re: RFR: 8003380 - Compiler warnings in logging test code
On 14/11/2012 22:44, Chris Hegarty wrote: - @SuppressWarnings(unused) Eclipse??? Do we have precedent for adding these suppressions?? I don't see it in the -Xlint options that javac supports so it might be specific to ECJ. I recall this topic came up during one of the warnings clean-up days, Stuart might remember the outcome. -Alan
Re: RFR: 8003380 - Compiler warnings in logging test code
Jim, I'm not convinced that the use of unused is strictly necessary, but I'm not an Eclipse user. It looks like there is an easy way around this. For example, in new/test/java/util/logging/LoggingDeadlock3.java, rather than add @SuppressWarnings(unused), will the follow keep the compiler happy? Logger logger = Logger.getLogger(com.sun.Hello+cnt/10); --- Logger.getLogger(com.sun.Hello+cnt/10); ... and similar for other areas? Otherwise, I'm happy with the change and can push is for you. -Chris On 14/11/2012 23:13, Jim Gish wrote: I've updated the webrev with your suggestion. Here it is: http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ Could someone please push it? Thanks, Jim On 11/14/2012 05:48 PM, Jim Gish wrote: On 11/14/2012 05:44 PM, Chris Hegarty wrote: Interesting... fixing warnings in tests. A few comments. Right -- one might consider it overkill sine the warnings don't show up in normal testing, but they do show up in Eclipse. Just plain annoying. - LoggingMXBeanTest2.java ListIterator? - ListIteratorString and remove redundant cast ? ok. - @SuppressWarnings(unused)Eclipse??? Do we have precedent for adding these suppressions?? Not that I know of. - ClassLoaderLeakTest Why the change to use toURI().toURL() ?? Because directly applying .toURL() unless it is on a URI is deprecated. ...Jim -Chris On 14 Nov 2012, at 21:15, Jim Gish jim.g...@oracle.com mailto:jim.g...@oracle.com wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com mailto:jim.g...@oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
Well -- yes and no. The problem is the way Loggers are handled -- as weak refs. They can get easily gc'd. Now in this code it doesn't really make much difference, but I'm trying to be consistent. That said, the right thing, now that I look at it again, would be to make the declarations of logger static, to ensure they don't get gc'd. Initially I thought that instance variables would do the trick, but I've since learned otherwise. (There's much more behind the curtain here than I previously thought :-( ) Thanks, Jim On 11/15/2012 10:52 AM, Chris Hegarty wrote: Jim, I'm not convinced that the use of unused is strictly necessary, but I'm not an Eclipse user. It looks like there is an easy way around this. For example, in new/test/java/util/logging/LoggingDeadlock3.java, rather than add @SuppressWarnings(unused), will the follow keep the compiler happy? Logger logger = Logger.getLogger(com.sun.Hello+cnt/10); --- Logger.getLogger(com.sun.Hello+cnt/10); ... and similar for other areas? Otherwise, I'm happy with the change and can push is for you. -Chris On 14/11/2012 23:13, Jim Gish wrote: I've updated the webrev with your suggestion. Here it is: http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ Could someone please push it? Thanks, Jim On 11/14/2012 05:48 PM, Jim Gish wrote: On 11/14/2012 05:44 PM, Chris Hegarty wrote: Interesting... fixing warnings in tests. A few comments. Right -- one might consider it overkill sine the warnings don't show up in normal testing, but they do show up in Eclipse. Just plain annoying. - LoggingMXBeanTest2.java ListIterator? - ListIteratorString and remove redundant cast ? ok. - @SuppressWarnings(unused) Eclipse??? Do we have precedent for adding these suppressions?? Not that I know of. - ClassLoaderLeakTest Why the change to use toURI().toURL() ?? Because directly applying .toURL() unless it is on a URI is deprecated. ...Jim -Chris On 14 Nov 2012, at 21:15, Jim Gish jim.g...@oracle.com mailto:jim.g...@oracle.com wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com mailto:jim.g...@oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
RFR: 8003380 - Compiler warnings in logging test code
Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
looks Ok. On Nov 14, 2012, at 4:15 PM, Jim Gish wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
Interesting... fixing warnings in tests. A few comments. - LoggingMXBeanTest2.java ListIterator? - ListIteratorString and remove redundant cast ? - @SuppressWarnings(unused) Eclipse??? Do we have precedent for adding these suppressions?? - ClassLoaderLeakTest Why the change to use toURI().toURL() ?? -Chris On 14 Nov 2012, at 21:15, Jim Gish jim.g...@oracle.com wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
On 11/14/2012 05:44 PM, Chris Hegarty wrote: Interesting... fixing warnings in tests. A few comments. Right -- one might consider it overkill sine the warnings don't show up in normal testing, but they do show up in Eclipse. Just plain annoying. - LoggingMXBeanTest2.java ListIterator? - ListIteratorString and remove redundant cast ? ok. - @SuppressWarnings(unused)Eclipse??? Do we have precedent for adding these suppressions?? Not that I know of. - ClassLoaderLeakTest Why the change to use toURI().toURL() ?? Because directly applying .toURL() unless it is on a URI is deprecated. ...Jim -Chris On 14 Nov 2012, at 21:15, Jim Gish jim.g...@oracle.com mailto:jim.g...@oracle.com wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com mailto:jim.g...@oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
Re: RFR: 8003380 - Compiler warnings in logging test code
I've updated the webrev with your suggestion. Here it is: http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ Could someone please push it? Thanks, Jim On 11/14/2012 05:48 PM, Jim Gish wrote: On 11/14/2012 05:44 PM, Chris Hegarty wrote: Interesting... fixing warnings in tests. A few comments. Right -- one might consider it overkill sine the warnings don't show up in normal testing, but they do show up in Eclipse. Just plain annoying. - LoggingMXBeanTest2.java ListIterator? - ListIteratorString and remove redundant cast ? ok. - @SuppressWarnings(unused) Eclipse??? Do we have precedent for adding these suppressions?? Not that I know of. - ClassLoaderLeakTest Why the change to use toURI().toURL() ?? Because directly applying .toURL() unless it is on a URI is deprecated. ...Jim -Chris On 14 Nov 2012, at 21:15, Jim Gish jim.g...@oracle.com mailto:jim.g...@oracle.com wrote: Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com mailto:jim.g...@oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.g...@oracle.com
