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
> <simon at dancingcloudservices.com> 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 <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