RFR(m): 8145468 deprecations for java.lang

[Martin Buchholz]

I don't think it's practical to ever remove the boxed primitive constructors.
Even less so for String, because the String(String) constructor used
to be an important optimization!

On Thu, Apr 14, 2016 at 4:25 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 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