I can confirm that the compiler is completely unaware of multi-arity
operators (the notion that + takes 2 OR MORE elements - it just takes
2 elements, no more, and multiple applications are merely this notion
chained), and that these are always resolved in a strict left-to-right
fashion.
You can see the same weird shenanigans when trying to add numbers and
non-numbers together:
5 + 3 + "foo" = "8foo".
"foo" + 5 + 3 = "foo53".
On Aug 27, 10:20 am, Christian Catchpole <christ...@catchpole.net>
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 <peter.becker...@gmail.com> 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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
