a quick question about String

[Alan Snyder]

Thanks. That makes sense.

Speaking of Valhalla, how is that coming along? Should I start reading about it now, or would it be better to wait?

  Alan



> On Dec 24, 2021, at 8:29 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 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 <javalists at 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 <simon at 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 <xenoamess at gmail.com> wrote:
>>> 
>>>> never should，as Object can be use as lock.
>>>> 
>>>> XenoAmess
>>>> ________________________________
>>>> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of
>>>> Bernd Eckenfels <ecki at zusammenkunft.net>
>>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>>> To: alan Snyder <fishgarage at cbfiddle.com>; core-libs-dev <
>>>> core-libs-dev at 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-retn at openjdk.java.net> im Auftrag von
>>>> Alan Snyder <javalists at cbfiddle.com>
>>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>>> An: core-libs-dev <core-libs-dev at 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
>>> 
>> 
>