Because you might want to put a breakpoint on that line of code and debug the variables going in and coming out.
replyBut further, optimizing in the compiler can preclude future optimizations by the JIT. Giving the JIT more information can make it make better decisions.
Also, the JIT needs to do that optimization anyways. If a class was compiled with Java 1.0, it might miss some optimizations introduced in the Java 27 compiler. To cover for that, the JVM 27 will need in it's jit the optimizations which were missing from the 1.0 javac if it wants to keep making the code go faster.
That's why the JVM developers have ultimately pushed to make javac pretty dumb and the JIT pretty smart. They can make much better optimizations in the JIT which are retroactive.
This is a good list. Other reasons are that the JIT has more information about the program. The Java-to-bytecode compiler never sees the whole application, and it knows nothing about which program paths are actually executed in practice. The JIT compiler, in contrast, knows about the loaded class hierarchy, and it has access to type and branch profile information. This enables the JIT to do aggressive inlining of method calls and pruning of branches that are never executed. These are probably the most important transformations that lead to the discovery of opportunities for these mask optimizations. The source code that javac sees will contain very few relevant cases.
replyThe Java compiler almost does ZERO optimizations.
replySo you really want to you should ask why the JIT rather than compiler does optimizations in Java?