As the language currently stands, new means new; it is guaranteed to create a
new identity. (When Valhalla comes along, instances of certain classes will be
identity-free, so the meaning of new will change somewhat, but String seems
likely to stay as it is.)
The language is allowed (in some cases required) to intern string _literals_,
so the expression
“foo” == “foo”
can be true. That’s OK because no one said “new”.
In your example, the two instances would not be ==, but would be .equals. But
since “equivalent” is not a precise term, we can have an angels-on-pins debate
about whether they are indeed equivalent. IMO equivalent here means “for
practical purposes”; locking on an arbitrary string which you did not allocate
is a silly thing to do, so it is reasonable that the doc opted for a
common-sense interpretation of equivalent, rather than a more precise one.
> On Dec 24, 2021, at 11:12 AM, Alan Snyder <javali...@cbfiddle.com> wrote:
>
> Just when I thought the answer was simple, now it seems more complex.
>
> Are you saying that new would always create a new object but the GC might
> merge multiple instances of String into a single instance?
>
> Also, if new String() always creates a new instance, then it seems that this
> statement (from String.java) is not quite right:
>
> Because String objects are immutable they can be shared. For example:
>
> String str = "abc";
> is equivalent to:
>
> char data[] = {'a', 'b', 'c'};
> String str = new String(data);
>
>
>
>
>> On Dec 23, 2021, at 2:55 PM, Simon Roberts <si...@dancingcloudservices.com>
>> wrote:
>>
>> I think there are two things at stake here, one is that as I understand it,
>> "new means new", in every case. This is at least partly why the
>> constructors on soon-to-be value objects are deprecated; they become
>> meaningless. The other is that if the presumption is that we should
>> always intern new Strings, I must disagree. Pooling takes time and memory
>> to manage, and if there are very few duplicates, it's a waste of both. I
>> believe it should be up to the programmer to decide if this is appropriate
>> in their situation. Of course, the GC system seems to be capable of
>> stepping in in some incarnations, which adds something of a counterexample,
>> but that is, if I recall, configurable.
>>
>>
>> On Thu, Dec 23, 2021 at 2:53 PM Xeno Amess <xenoam...@gmail.com> wrote:
>>
>>> never should，as Object can be use as lock.
>>>
>>> XenoAmess
>>> ________________________________
>>> From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of
>>> Bernd Eckenfels <e...@zusammenkunft.net>
>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>> To: alan Snyder <fishgar...@cbfiddle.com>; core-libs-dev <
>>> core-libs-dev@openjdk.java.net>
>>> Subject: Re: a quick question about String
>>>
>>> new String() always creates a new instance.
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> ________________________________
>>> Von: core-libs-dev <core-libs-dev-r...@openjdk.java.net> im Auftrag von
>>> Alan Snyder <javali...@cbfiddle.com>
>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>> An: core-libs-dev <core-libs-dev@openjdk.java.net>
>>> Betreff: a quick question about String
>>>
>>> Do the public constructors of String actually do what their documentation
>>> says (allocate a new instance), or is there some kind of compiler magic
>>> that might avoid allocation?
>>>
>>>
>>
>> --
>> Simon Roberts
>> (303) 249 3613
>>
>
