That's how all compilers I've seen do things. It's all just parser rules and associativity that maps to unary or binary tree nodes which then is collapsed in the desugar/optimizer phase. Nothing unusual about that, classic divide and conquer I'd say.
/Casper On 27 Aug., 14:45, Reinier Zwitserloot <[email protected]> wrote: > 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 <[email protected]> > 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 -~----------~----~----~----~------~----~------~--~---
