I think the + syntax in all possible cases with the maximal performance
would be the best option indeed. While we are not there yet, we could go
for this small change to improve existing code since the difference of
performance is significant.
To make this proposal more explicit, I'm going to
Am 12.02.2013 01:45, schrieb Vitaly Davidovich:
javac will not replace concat ops across loop iterations, it will replace whichever ones are
inside one loop iteration. This will still create temporary StringBuilder instances.
As for JIT optimizing further, it would have to fully unroll the
Hello,
we have a scenario where a project with approximately 500K lines of code is
going through a large refactoring. One of the changes was to replace string
concatenations in loops by StringBuilder. Within the logic we found the
following condition:
for(...) {
if(str.isEmpty()) {
//
This could be a default method in CharSequence
Regards, Peter
On 02/11/2013 12:54 PM, Hildeberto Mendonça wrote:
Hello,
we have a scenario where a project with approximately 500K lines of code is
going through a large refactoring. One of the changes was to replace string
concatenations in
Yes. That's definitively a good approach. I think there are many other
opportunities to improve StringBuilder and other subclasses of
CharSequence, but this isEmpty() method is a very important one. A lot of
developers might be constantly doing this kind of refactoring and it may
reduce the effort
Am 11.02.2013 12:54, schrieb Hildeberto Mendonça:
Hello,
we have a scenario where a project with approximately 500K lines of code is
going through a large refactoring. One of the changes was to replace string
concatenations in loops by StringBuilder.
Are you aware, that behind the scenes,
It won't replace them in loops or at least not entirely (may get
intermediate builders for each iteration).
I also agree on the isEmpty() point.
Sent from my phone
On Feb 11, 2013 9:30 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 11.02.2013 12:54, schrieb Hildeberto Mendonça:
Hello,
we have
On Mon, Feb 11, 2013 at 3:29 PM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 11.02.2013 12:54, schrieb Hildeberto Mendonça:
we have a scenario where a project with approximately 500K lines of code is
going through a large refactoring. One of the changes was to replace
string
concatenations in
Do you want isEmpty() for bean access, or empty() like Collections? Since
there isn't a getLength() but just length() (and size() for collections), I
think the latter would be preferred.
Paul
It should be isEmpty() -- empty() is usually for returning empty versions
of the class. isEmpty is also consistent with String.
Sent from my phone
On Feb 11, 2013 12:03 PM, Paul Benedict pbened...@apache.org wrote:
Do you want isEmpty() for bean access, or empty() like Collections? Since
On Mon, Feb 11, 2013 at 6:08 PM, Vitaly Davidovich vita...@gmail.comwrote:
It should be isEmpty() -- empty() is usually for returning empty versions
of the class. isEmpty is also consistent with String.
Yes. Also, being consistent with String helps to reduce effort during
refactoring.
--
Is there something we can do to push it forward? Maybe a patch, tests,
text, or something else?
On Mon, Feb 11, 2013 at 7:32 PM, Hildeberto Mendonça m...@hildeberto.comwrote:
On Mon, Feb 11, 2013 at 6:08 PM, Vitaly Davidovich vita...@gmail.comwrote:
It should be isEmpty() -- empty() is
Am 11.02.2013 16:39, schrieb Hildeberto Mendonça:
On Mon, Feb 11, 2013 at 3:29 PM, Ulf Zibis ulf.zi...@cosoco.de
mailto:ulf.zi...@cosoco.de wrote:
Am 11.02.2013 12:54, schrieb Hildeberto Mendonça:
we have a scenario where a project with approximately 500K lines of
code is
Am 11.02.2013 22:26, schrieb Hildeberto Mendonça:
Hello Ulf,
On Mon, Feb 11, 2013 at 9:03 PM, Ulf Zibis ulf.zi...@cosoco.de
mailto:ulf.zi...@cosoco.de wrote:
Hi Hildeberto,
maybe your believe is correct.
You could have a look in the byte code by javap.
And additionally you
javac will not replace concat ops across loop iterations, it will replace
whichever ones are inside one loop iteration. This will still create
temporary StringBuilder instances.
As for JIT optimizing further, it would have to fully unroll the loop to
have a chance at eliminating this; I'd be
15 matches
Mail list logo
