RFR(m): 8145468 deprecations for java.lang

[Stuart Marks]

On 4/14/16 10:10 AM, Martin Buchholz wrote:
> I've been tempted by the dark side, when a class needs a value AND a
> lock (or an "identity").  Instead of doing
>
> final String val = "foo";
> final Object lock = new Object();
>
> one can "optimize" this ("why can't we have both?") to
>
> final String valAndLock = new String("foo");
>
> and there are surely folks out there doing this.  We should probably
> never remove those constructors.

Only at the end do you realize the power of the Dark Side.

The String constructors aren't part of this round of deprecations. The main 
effort here is to try to clear some room to "valorize" (as John Rose puts it) 
the boxed primitives, and to make it clear that depending on identity semantics 
for the boxes is something that's officially frowned upon. (ASM notwithstanding. 
Ahem.) So that's why we're focusing on the boxed primitive constructors.

Valorizing Strings is altogether a different matter. I'm not entirely sure how 
this will turn out. But weren't not yet at the point of deprecating the 
String(String) constructor, much less deprecating it for removal. So this kind 
of evil hack will remain safe for the time being.

s'marks