So it's not that the optimization fails but there is no optimization on them
yet.
I do see the .append("x") case will be easy to deal with, but it looks like
historically javac has not been a place to do many optimizations. It mostly
converts the java source to byte codes in a 1-to-1 mapping and let VM do
whatever it wants (to optimize). When you talked about compiling multiple
concatenation into using a single StringBuilder, it's more like choosing the
correct implementation rather than an optimization.
I don't expect to see big change on this in the near future, so shall we go on
with the current enhancement?
Thanks
Max
On Aug 29, 2014, at 2:17, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
> I mean:
> It does not output byte code that only uses a single char array to compose
> the entire String in question.
> With "optimization fails", I also mean, there is used an additional
> "StringComposer" e.g. another StringBuilder or a StringJoiner in addition to
> the 1st StringBuilder.
>
> -Ulf
>
> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>> Could you please explain what you mean by "javac optimization fails" here?
>>
>> -Pavel
>>
>> On 27 Aug 2014, at 10:41, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
>>
>>> 4.) Now we see, that javac optimization fails again if StringBuilder,
>>> concatenation, toString(), append(String), append(Collection) etc. and
>>> StringJoiner use is mixed.
>>
>
