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
