Sometimes, javac apparently decides not to be utterly stupid. Sometimes it optimizes. Here’s the special case: When a program locks this, which is always present in local variable 0 in non-static methods, it does not allocate an additional local variable. I expected the following:
GeSHi Error: GeSHi could not find the language jvm (using path /home/dh_8dhf9b/concurrentaffair.org/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
But in this case, javac is smart enough to realize that aload_0 already contains this, so it generates
GeSHi Error: GeSHi could not find the language jvm (using path /home/dh_8dhf9b/concurrentaffair.org/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
But, of course, if the user declares a local variable, like in the following example, javac does not recognize this. This Java code
1 2 3 4 |
mercilessly generates this bytecode:
GeSHi Error: GeSHi could not find the language jvm (using path /home/dh_8dhf9b/concurrentaffair.org/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
Now I have to put more conditionals into my code. Yuck. I hope there aren’t more of these rare optimizations hidden somewhere. All of this gives me a bad feeling about relying on my perception of what javac generates. It would be much more prudent to just rely on the VM specifications, as I did before.
