Order of execution of parameters guarantees in Java?

Question

Given the following function call in C:

fooFunc( barFunc(), bazFunc() );

The order of execution of barFunc and BazFunc is not specified, so barFunc() may be called before bazFunc() or bazFunc() before barFunc() in C.

Does Java specify an order of execution of function argument expressions or like C is that unspecified?

Solution

From the Java Language Specification (on Expressions):

15.7.4 Argument Lists are Evaluated Left-to-Right

In a method or constructor invocation or class instance creation expression, argument expressions may appear within the parentheses, separated by commas. Each argument expression appears to be fully evaluated before any part of any argument expression to its right.

Comments

[Jon]

While this is true, please please don't code in a way that makes it dependent on execution order. It's just adding complexity without adding functionality.

[trashgod]

Indeed, "It is recommended that code not rely crucially on this specification." java.sun.com/docs/books/jls/third_edition/html/…

[John Henckel]

@Jon I disagree! if it is in the specification, then you can rely on it. For example, to read a rectangle from a file, I use this code: myRect = new Rectangle(scan.nextInt(), scan.nextInt(), scan.nextInt(), scan.nextInt()); It is concise and simple. A longer implementation would be unnecessary complexity.

[CoffeDeveloper]

I used that to avoid saving local variables in many places and made code shorter 1/2 lines for each funcion call in a parser :D. Avoiding many local variables (unless that creates more complex code) is usually good design too.

[Steven Jeffries]

Joining this party a bit late, but I have a method to combine bytes to an int that I call like this: toInt(data[offset++], data[offset++], data[offset++], data[offset++]). I'm far too lazy to change this code, so I'm glad it will work.

[Jeff G]

@Jon If Java allowed temporary variable declaration prior to constructor chaining calls, I would agree with you. However, I see no viable alternative to relying on this behavior when combining constructor chaining with complex member initialization.

[raven]

@JohnHenckel Your example is fine. But imagine if instead of Rectangle you had new MyClass(...) and after a while you decide to reorder MyClass's constructor arguments; the IDE will automatically fix the usages for you but this results in a hard to find bug since the order of the argument resolution should have been preserved. You should be careful when using this.