RFR(m): 8145468u1 deprecations for java.lang

[Dave Brosius]

Greetings,

Along these lines, is there a reason not to deprecate the

String(String s)

constructor? Now that substring doesn't glom off the original string, i 
see no reason for this constructor.

-dave

On 04/15/2016 06:36 PM, Stuart Marks wrote:
> Hi all,
>
> Here's a small update to the jdk repo webrev for this change. There 
> are no changes to any API deprecations or other specification changes. 
> The changes are confined to the warnings cleanup work.
>
> http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.1.jdk/
>
> The files changed relative to the previous webrev are as follows.
>
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java
>
>  - revert autoboxing per Remi, add @SuppressWarnings and comments
>
> src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java
> src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionExecuter.java
>
>  - cleanups as suggested by Paul
>
> src/java.base/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java 
>
> src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java 
>
>
>  - cleanups to windows files that I had missed previously
>
> There are also no changes to langtools or top repo; those webrevs are 
> unchanged:
>
> http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.langtools/
> http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.top/
>
> Thanks,
>
> s'marks
>
>
>