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 -~----------~----~----~----~------~----~------~--~---
