I thought your comment to my post was quite appropriate -- I really had misread Alexey's post.
But maybe we are just entangled in some weird kind of dance, missing each others point until the end of time. Or something. Bedtime. Peter Christian Catchpole wrote: > Maybe I missed your point :) I thought the original question was why > > getOne() + "two " + "three" > > doesnt become > > getOne() + "two three" > > even if it was > > getTotallyRandom() + "two three" > > On Aug 27, 9:07 pm, Peter Becker <[email protected]> wrote: > >> I did miss the point (or in fact the little word "not"). >> >> I think your theory is probably right, although in the absence of >> arbitrary operator overloading it seems quite clear what the type of >> (getOne() + "two ") is and since string concatenation is associative it >> would be a valid optimization. But it requires a bit more reasoning. >> >> Even with operator overloading the case would IMO still be clear since >> the return type of getOne() is exact due to String's finalness. But >> then: we are talking Java, other JVM languages might break some of these >> rules. >> >> Peter >> >> >> >> Christian Catchpole wrote: >> >>> hmm.. think you missed the point there peter. "two " + "three" == >>> "two three" regardless of what comes before it. But I think i might >>> know why the optimizer picks up >>> >>> "one " + "two " + "three" >>> >>> but not >>> >>> getOne() + "two " + "three" >>> >>> it probably sees this.. >>> >>> (("one " + "two ") + "three") >>> == >>> (("one two ") + "three") >>> == >>> ("one two three") >>> >>> It can collapse one two, then the third because they are all constant. >>> >>> ((getOne() + "two ") + "three") >>> >>> the first collapse produces something unpredictable. >>> >>> On Aug 27, 7:43 am, Peter Becker <[email protected]> wrote: >>> >>>> Alexey Zinger wrote: >>>> >>>>> There are quite a few optimizations with strings, for sure. Such as >>>>> replacing concatenation using "+" operator with StringBuilder and >>>>> concatenation of literals with a single literal (*). >>>>> >>>>> There's an interesting exception to that rule. The following will >>>>> work as expected: >>>>> "one " + "two " + "three" >>>>> gets turned into >>>>> "one two three" >>>>> >>>>> However, in the context of this: public String getOne() { return "one "; } >>>>> this: getOne() + "two " + "three" >>>>> will not get turned into >>>>> getOne() + "two three" >>>>> >>>> If I am not mistaken the compiler can not replace that without >>>> potentially breaking the code. You method is public and non-final, which >>>> means it can be overwritten, so you need the dynamic dispatch, inlining >>>> is not ok. >>>> >>>> The JIT might do a different thing since it knows the state of the >>>> running system. If it should optimize that call it will need to be able >>>> to revert it if a baseclass of the class you describe is loaded. >>>> >>>> If the method getOne() would be either final or private, then the >>>> compiler should theoretically be able to inline it. No idea if it would. >>>> >>>> Peter >>>> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
