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
