Let\'s imagine we have the following classes:
public class Message extends Object {}
public class Logger implements ILogger {
public void log(Message m) {/
Will the Java compiler strip out statements
a
andb
?
The javac
(source to bytecode) compiler won't strip either call. (It is easy to check this by examining the bytecodes; e.g. looking at the javap -c
output.)
In both cases (stripping or not stripping), what is the rationale behind the Java compiler's decision ?
Conformance with the JLS :-).
From a pragmatic perspective:
javac
compiler optimized the calls away, a Java debugger wouldn't be able to see them at all ... which would be rather confusing for the developer.Early optimization (by javac
) would result in breakage if the Message
class and the main class were compiled / modified independently. For example, consider this sequence:
Message
is compiled,Message
is edited so that log
does something ... and recompiled.Now we have an incorrectly compiled main class that doesn't do the right thing at a
and b
because the prematurely inlined code is out of date.
However, the JIT compiler might optimize the code at runtime in a variety of ways. For instance:
The method calls in a
and b
may be inlined if the JIT compiler can deduce that no virtual method dispatching is required. (If Logger
is the only class used by the application that implements ILogger
this a no-brainer for a good JIT compiler.)
After inlining the first method call, the JIT compiler may determine that the body is a noop and optimize the call away.
In the case of the second method call, the JIT compiler could further deduce (by escape analysis) that the Message
object doesn't need to be allocated on the heap ... or indeed at all.
(If you want to know what the JIT compiler (on your platform) actually does, Hotspot JVMs have a JVM option that dumps out the JIT-compiled native code for selected methods.)