yes that's.. i have a habit of posting.. re-reading.. and doh!-ing :)
On Aug 27, 10:40 pm, Peter Becker <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
