Let’s imagine we have the following classes:
public class Message extends Object {}
public class Logger implements ILogger {
public void log(Message m) {/*empty*/}
}
and the following program:
public static void main(String args[]) {
ILogger l = new Logger();
l.log((Message)null); // a)
l.log(new Message()); // b)
}
Will the Java compiler strip out statements a and b ? In both cases (stripping or not stripping), what is the rationale behind the Java compiler’s decision ?
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 thejavap -coutput.)Conformance with the JLS :-).
From a pragmatic perspective:
javaccompiler 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 theMessageclass and the main class were compiled / modified independently. For example, consider this sequence:Messageis compiled,Messageis edited so thatlogdoes something … and recompiled.Now we have an incorrectly compiled main class that doesn’t do the right thing at
aandbbecause 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
aandbmay be inlined if the JIT compiler can deduce that no virtual method dispatching is required. (IfLoggeris the only class used by the application that implementsILoggerthis 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
Messageobject 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.)