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

[Steven Schlansker]

> On Apr 18, 2016, at 3:30 PM, Stuart Marks  wrote:
> 
> On 4/17/16 7:06 AM, Dave Brosius wrote:
>> 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.
> 
> It's a fair point. But I think that historically there's been much greater 
> awareness of Strings' identity than that of boxed primitives.
> 
> At issue is string interning. When you compile a Java program, a string 
> literal like "foo" is unavoidably interned. This is wired deeply into the 
> language, compiler, and JVM, and has been so since 1.0.
> 
> With boxed primitives, there is autoboxing, but it's only been around since 
> Java 5. ("Only" 11 years.) There is a cache, and although this is mandated by 
> the JLS, it's actually maintained only by the library.
> 
> The notion of identity of strings seems stronger, thus there's a greater need 
> for new String(String) if you want to guarantee a string has a unique 
> identity.
> 
> It also seems much more likely for us to be able to turn boxed primitives 
> into values than to turn strings into values. (One issue is that strings can 
> be of all different sizes, whereas all instances/values of a boxed primitive 
> are of the same size.) Thus there appears to be a greater benefit to 
> migrating code away from the box constructors than from the String(String) 
> constructor.
> 
> This is probably something that should be revisited at some point, though. 
> There are probably more misuses of String(String) out there than there are 
> legitimate uses.

As an example of a useful use of the new String(String) constructor, I once 
wrote (pseudo) code:

WeakHashMap memoTable = new WeakHashMap<>();
public String memoTransform(String key) {
String value = memoTable.get(key);
if (value != null) return value;
value = transform(key);  // Might be identity function and return 'key'
memoTable.put(key, (key == value) ? new String(value) : value);
}

If you aren't careful to copy your value in this sort of situation, you can end 
with
never-collectible entries and therefore memory leaks in your weak hash table.

If substring were specified to always return unique objects, that could work as 
well --
but in my opinion the copy constructor is clearer when object identity is 
important,
and it looks like String sensibly avoids unnecessary copying:

String.java:1933  return (beginIndex == 0) ? this : new String(value, 
beginIndex, subLen);

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

[Stuart Marks]

On 4/17/16 7:06 AM, Dave Brosius wrote:

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.


It's a fair point. But I think that historically there's been much greater 
awareness of Strings' identity than that of boxed primitives.


At issue is string interning. When you compile a Java program, a string literal 
like "foo" is unavoidably interned. This is wired deeply into the language, 
compiler, and JVM, and has been so since 1.0.


With boxed primitives, there is autoboxing, but it's only been around since Java 
5. ("Only" 11 years.) There is a cache, and although this is mandated by the 
JLS, it's actually maintained only by the library.


The notion of identity of strings seems stronger, thus there's a greater need 
for new String(String) if you want to guarantee a string has a unique identity.


It also seems much more likely for us to be able to turn boxed primitives into 
values than to turn strings into values. (One issue is that strings can be of 
all different sizes, whereas all instances/values of a boxed primitive are of 
the same size.) Thus there appears to be a greater benefit to migrating code 
away from the box constructors than from the String(String) constructor.


This is probably something that should be revisited at some point, though. There 
are probably more misuses of String(String) out there than there are legitimate 
uses.


s'marks

Re: 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

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

[Stuart Marks]

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