Re: a quick question about String

[Andrew Haley]

On 12/30/21 16:12, Alexander Scherbatiy wrote:

Would it be useful to have some kind of an immutable array in Java language
which works in the same way as ordinary array except it is not to
possible to change
its values after creation?


Yes.  https://openjdk.java.net/jeps/8261007

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: a quick question about String

[Kim Barrett]

> On Dec 24, 2021, at 2:46 PM, liangchenb...@gmail.com wrote:
> 
>> Are you saying that new would always create a new object but the GC might 
>> merge multiple instances of String into a single instance?
> 
> About jvm's string optimizations, jvm may make different string
> objects with the same content share the backing array in order to
> reduce allocation (like what the original poster alan wonders). This
> optimization does not alter the identity of the relative string
> objects and thus has zero effect on the user end.

For HotSpot this is enabled by -XX:+UseStringDeduplication.
For more details see https://openjdk.java.net/jeps/192
Note that as of JDK 18 all of the HotSpot collectors support this, not just G1.

Re: a quick question about String

[Raffaello Giulietti]

Hello,

the simple answer is that
new String(...) == new String(...)
*never* evaluates to true )it might throw, though), whatever 
constructors you are using and whatever arguments you pass to to them.


Some garbage collectors *might* de-duplicate the underlying arrays (but 
you cannot tell), but the references to the Strings will be different.



HTH
Raffaello


On 2021-12-23 18:59, Alan Snyder wrote:

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?

Re: a quick question about String

[Alexander Scherbatiy]

On 12/24/21 10:33 AM, Enrico Olivelli wrote:


Alan,
are you talking about the fact that you cannot "wrap" an existing
byte[] that you know that you are already encoded ?

In that case the main problem is that the String is supposed to be
immutable and when you pass the byte[] it must be copied in order to
prevent someone else to modify the contents of the array behind the String


In java desktop where are arrays which values once created are not 
updated anymore.
It needs to make a defensive copy of such arrays every time when the 
arrays are used
by other classes to prevent them from being modified outside (InputEvent 
[1],  SunFontManager [2], JOptionPane [3]).


Would it be useful to have some kind of an immutable array in Java language
which works in the same way as ordinary array except it is not to 
possible to change

its values after creation?

[1] 
https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/java/awt/event/InputEvent.java#L218
[2] 
https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/sun/font/SunFontManager.java#L3337
[3] 
https://github.com/openjdk/jdk/blob/299022dfacbcb49e3bc5beca8ff9b1fca1101493/src/java.desktop/share/classes/javax/swing/JOptionPane.java#L2010


Thanks,
Alexander.

Enrico

Il giorno gio 23 dic 2021 alle ore 23:56 Simon Roberts
 ha scritto:

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


never should，as Object can be use as lock.

XenoAmess

From: core-libs-dev  on behalf of
Bernd Eckenfels 
Sent: Friday, December 24, 2021 5:51:55 AM
To: alan Snyder ; 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  im Auftrag von
Alan Snyder 
Gesendet: Thursday, December 23, 2021 6:59:18 PM
An: core-libs-dev 
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

Re: a quick question about String

[-]

a more precise
> > one.
> >
> >
> >
> > > On Dec 24, 2021, at 11:12 AM, Alan Snyder 
> > 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  wrote:
> > >>
> > >>> never should，as Object can be use as lock.
> > >>>
> > >>> XenoAmess
> > >>> 
> > >>> From: core-libs-dev  on behalf of
> > >>> Bernd Eckenfels 
> > >>> Sent: Friday, December 24, 2021 5:51:55 AM
> > >>> To: alan Snyder ; 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  im Auftrag
> > von
> > >>> Alan Snyder 
> > >>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
> > >>> An: core-libs-dev 
> > >>> 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
> > >>
> > >
> >
> >

Re: 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  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  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  
>>> 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  wrote:
>>> 
>>>> never should，as Object can be use as lock.
>>>> 
>>>> XenoAmess
>>>> 
>>>> From: core-libs-dev  on behalf of
>>>> Bernd Eckenfels 
>>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>>> To: alan Snyder ; 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  im Auftrag von
>>>> Alan Snyder 
>>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>>> An: core-libs-dev 
>>>> 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
>>> 
>> 
> 

Re: a quick question about String

[Xeno Amess]

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

class SyncDemo1 {

static volatile int count;

public static void add() {
synchronized (Demo.getString1()) {
System.out.println("count1 : " + (count++));
}
}

}

class SyncDemo2 {

static volatile int count;

public static void add() {
synchronized (Demo.getString2()) {
System.out.println("count2 : " + (count++));
}
}

}

public class Demo {

public static String getString1() {
String str = "abc";
return str;
}

public static String getString2() {
char data[] = {'a', 'b', 'c'};
String str = new String(data);
return str;
}

public static void main(String[] args) throws InterruptedException {
System.out.println("test1");
ExecutorService executorService1 = Executors.newFixedThreadPool(20);
for (int i = 0; i < 1000; i++) {
executorService1.submit(
SyncDemo1::add
);
}

ExecutorService executorService2 = Executors.newFixedThreadPool(20);
for (int i = 0; i < 1000; i++) {
executorService2.submit(
SyncDemo2::add
);
}
}

}


run the codes I send you, at a multi-core machine.
count1 can remain sequential, but count2 not.
That is what I said several hours ago : never should，as Object can be use
as lock.
And String is a kind of Object.


Brian Goetz  于2021年12月25日周六 00:29写道：

> 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 
> 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  wrote:
> >>
> >>> never should，as Object can be use as lock.
> >>>
> >>> XenoAmess
> >>> 
> >>> From: core-libs-dev  on behalf of
> >>> Bernd Eckenfels 
> >>> Sent: Friday, December 24, 2021 5:51:55 AM
> >>> To: alan Snyder ; 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  im Auftrag
> von
> >>> Alan Snyder 
> >>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
> >>> An: core-libs-dev 
> >>> 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
> >>
> >
>
>

Re: a quick question about String

[Brian Goetz]

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  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  
>> 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  wrote:
>> 
>>> never should，as Object can be use as lock.
>>> 
>>> XenoAmess
>>> ____
>>> From: core-libs-dev  on behalf of
>>> Bernd Eckenfels 
>>> Sent: Friday, December 24, 2021 5:51:55 AM
>>> To: alan Snyder ; 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  im Auftrag von
>>> Alan Snyder 
>>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>>> An: core-libs-dev 
>>> 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
>> 
> 

Re: a quick question about String

[Alan Snyder]

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  
> 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  wrote:
> 
>> never should，as Object can be use as lock.
>> 
>> XenoAmess
>> 
>> From: core-libs-dev  on behalf of
>> Bernd Eckenfels 
>> Sent: Friday, December 24, 2021 5:51:55 AM
>> To: alan Snyder ; 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  im Auftrag von
>> Alan Snyder 
>> Gesendet: Thursday, December 23, 2021 6:59:18 PM
>> An: core-libs-dev 
>> 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
> 

Re: a quick question about String

[Enrico Olivelli]

Alan,
are you talking about the fact that you cannot "wrap" an existing
byte[] that you know that you are already encoded ?

In that case the main problem is that the String is supposed to be
immutable and when you pass the byte[] it must be copied in order to
prevent someone else to modify the contents of the array behind the String


Enrico

Il giorno gio 23 dic 2021 alle ore 23:56 Simon Roberts
 ha scritto:
>
> 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  wrote:
>
> > never should，as Object can be use as lock.
> >
> > XenoAmess
> > 
> > From: core-libs-dev  on behalf of
> > Bernd Eckenfels 
> > Sent: Friday, December 24, 2021 5:51:55 AM
> > To: alan Snyder ; 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  im Auftrag von
> > Alan Snyder 
> > Gesendet: Thursday, December 23, 2021 6:59:18 PM
> > An: core-libs-dev 
> > 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

Re: a quick question about String

[Simon Roberts]

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

> never should，as Object can be use as lock.
>
> XenoAmess
> 
> From: core-libs-dev  on behalf of
> Bernd Eckenfels 
> Sent: Friday, December 24, 2021 5:51:55 AM
> To: alan Snyder ; 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  im Auftrag von
> Alan Snyder 
> Gesendet: Thursday, December 23, 2021 6:59:18 PM
> An: core-libs-dev 
> 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

Re: a quick question about String

[Xeno Amess]

never should，as Object can be use as lock.

XenoAmess

From: core-libs-dev  on behalf of Bernd 
Eckenfels 
Sent: Friday, December 24, 2021 5:51:55 AM
To: alan Snyder ; core-libs-dev 

Subject: Re: a quick question about String

new String() always creates a new instance.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Alan 
Snyder 
Gesendet: Thursday, December 23, 2021 6:59:18 PM
An: core-libs-dev 
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?

Re: a quick question about String

[Bernd Eckenfels]

new String() always creates a new instance.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von Alan 
Snyder 
Gesendet: Thursday, December 23, 2021 6:59:18 PM
An: core-libs-dev 
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?