Is Java evaluation order guaranteed in this case of method call and arguments passed in

Question

I did some reading up on JLS 15.7.4 and 15.12.4.2, but it doesn't guarantee that there won't be any compiler/runtime optimization that would change the order in which method arguments are evaluated.

Assume the following code:

public static void main (String[] args) {
  MyObject obj = new MyObject();
  methodRelyingOnEvalOrder(obj, obj.myMethod());
}

public static Object methodRelyingOnEvalOrder(MyObject obj, Object input) {
  if (obj.myBoolean())
    return null;
  else
    return input;
}

Is it guaranteed that the compiler or runtime will not do a false optimization such as the following? This optimization may appear correct, but it is wrong when the order of evaluation matters.

In the case where calling obj.myMethod alters the value that will be returned by obj.myBoolean, it is crucial that obj.myMethod be called first as methodRelyingOnEvalOrder requires this alteration to happen first.

//*******************************
//Unwanted optimization possible:
//*******************************
public static void main (String[] args) {
  MyObject obj = new MyObject();
  methodRelyingOnEvalOrder(obj);
}

public static Object methodRelyingOnEvalOrder(MyObject obj) {
  if (obj.myBoolean())
    return null;
  else
    return obj.myMethod();
}
//*******************************

If possible, please show some sources or Java documentation that supports your answer.

Note: Please do not ask to rewrite the code. This is a specific case where I am questioning the evaluation order guarantee and the compiler/runtime optimization guarantee. The execution of obj.myMethod must happen in the main method.

Karalynn

You can sure the javac does almost no optimisations at all, it is all done by the JIT. While it may re-order or even eliminate the method call, the end behaviour should be the same. – Unfavorable

Answer 1

The bit of the JLS you referred to (15.7.4) does guarantee that:

Each argument expression appears to be fully evaluated before any part of any argument expression to its right.

and also in 15.12.4.2:

Evaluation then continues, using the argument values, as described below.

The "appears to" part allows for some optimization, but it must not be visible. The fact that all the arguments are evaluated before "evaluation then continues" shows that the arguments are really fully evaluted before the method executes. (Or at least, that's the visible result.)

So for example, if you had code of:

int x = 10;
foo(x + 5, x + 20);

it would be possible to optimize that to evaluate both x + 5 and x + 20 in parallel: there's no way you could detect this occurring.

But in the case you've given, you would be able to detect the call to obj.myMethod occurring after the call to obj.myBoolean(), so that wouldn't be a valid optimization at all.

In short: you're fine to assume that everything will execute in the obvious way here.

Trestlework

Can you further explain what the JLS means by appears to be and why it is not is? And what does not being visible mean? – Karalynn

@ADTC: It means you won't be able to detect any optimization here - it's a truly invisible optimization, if any is applied. – Trestlework

My gut agrees, but what that section actually says (the part you left out) is If the evaluation of any argument expression completes abruptly, then no part of any argument expression to its right appears to have been evaluated. It does not, at least from what I see in that section, explicitly specify what the apparent evaluation order should be if none of the evaluations complete abruptly. – Inspirit

@Jon What kind of invisible optimizations can happen? Can it do the one suggested in my second code block? If yes, in what circumstances? If no, then all is good :) – Karalynn

@JasonC: I left that out as I didn't feel it was immediately relevant. That part is in a separate paragraph to the bit that I quoted - there's no indication (as far as I can tell) that the apparent evaluation order is predicated on any evaluation completing abruptly. – Trestlework

@ADTC: No, the one in your second code block wouldn't be invisible, would it? You could detect it, so it's not a valid optimization. – Trestlework

@JonSkeet It's very relevant, I think, because it is quite different from "arguments always appear to be evaluated left to right". It only says that if one of the evaluations throw an exception, then the ones to the right do not appear to be evaluated. It does not say what you claimed it says. This isn't a criticism of you, sorry if it reads that way. It's just not how I'm reading that section. – Inspirit

@JasonC: No, that's a different paragraph. The bit that I quoted does not depend on the bit you're quoting. Those are two independent guarantees. (Or rather, I'd say that the bit you're quoting just clarifies the bit I'm quoting in the case of an exception. It doesn't in any way say "the previous paragraph doesn't apply if no exceptions are thrown.") – Trestlework

Oh. It's in 15.7.4, not 15.12.4.2. – Inspirit

@JasonC: Fixed that, thanks. I had both bits open in different tabs - copied the wrong number :( – Trestlework

Thanks both. @JasonC he is right, it's a different guarantee. But you are also right that it's relevant. For example if myMethod can throw an exception, the order in which it is executed relative to myBoolean (which may also throw an exception) determines which exception is thrown when either could be thrown. But as Jon has pointed out, it is guaranteed that the order as I wrote in code is guaranteed (no visible optimization) during runtime, so all is good. – Karalynn

@ADTC: As user2758929 pointed out in his answer, the "unwanted optimization" you proposed is not possible. If myMethod throws in your first example, myBoolean will never even be executed, as the argument evaluation must appear to happen first. – Inspirit

@JasonC yes, I agree. I'm just pointing out how your comment could be relevant to the question since throwing an exception is one form of "completes abruptly". – Karalynn

Answer 2

In addition to the argument evaluation order, the overview of the steps preformed when invoking a method, and their order, explained in section 15.12.4. Run-Time Evaluation of Method Invocation, makes it clear that all argument evaluations are performed before executing the method's code. Quote:

At run time, method invocation requires five steps. First, a target reference may be computed. Second, the argument expressions are evaluated. Third, the accessibility of the method to be invoked is checked. Fourth, the actual code for the method to be executed is located. Fifth, a new activation frame is created, synchronization is performed if necessary, and control is transferred to the method code.

The case you presented where an argument is only evaluated after control has been transferred to the method code is out of the question.

Chaotic

Thanks for your contribution. I can only accept one answer, but I have upvoted you :) – Karalynn