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