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 >> >