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 <[email protected]> wrote: > never should，as Object can be use as lock. > > XenoAmess > ________________________________ > From: core-libs-dev <[email protected]> on behalf of > Bernd Eckenfels <[email protected]> > Sent: Friday, December 24, 2021 5:51:55 AM > To: alan Snyder <[email protected]>; core-libs-dev < > [email protected]> > Subject: Re: a quick question about String > > new String() always creates a new instance. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: core-libs-dev <[email protected]> im Auftrag von > Alan Snyder <[email protected]> > Gesendet: Thursday, December 23, 2021 6:59:18 PM > An: core-libs-dev <[email protected]> > 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
