This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
It looks like something out of a convoluted C competition! Where did you find it?
Joined: Dec 19, 2011
I simply ran into this oddity while writing code for a coursework. The above is just a barebones example. I am sure I have seen this issue before, possibly when doing C++. Curiosity got the better of me.
While it's obvious to a human observer that "object" is never accessed, it's not to a compiler. To be on the safe side, the compiler needs to evaluate and compile the entire source code. Eliminating unused code sections is an optimization that takes extra work on the part of the compiler writer, and (at runtime) on the part of the compiler.
What's more, while the standard Java compiler (javac of the Oracle JDK) does detect, and optimize away, some similar code, this is actually tricky business. For example, the code you wrote (or rather the class it's in) uses the MyClass class - which means the class would need to be loaded when the class containing this code is executed (assuming that it hasn't been loaded before) - that would involve loading the MyClass class and executing its static initializers, which could do all kinds of things with side effects. If the optimizing compiler were to eliminate all traces of MyClass from this code, the resulting code might no longer work in the same way as the unoptimized code does. A bit of a contrived example, but it does point to some of the problems optimizing a language like Java raises.
Joined: Dec 19, 2011
I am not sure I fully understand what you are trying to communicate.
Tim Moores wrote:While it's obvious to a human observer that "object" is never accessed, it's not to a compiler.
Tim Moores wrote:If the optimizing compiler were to eliminate all traces of MyClass from this code [...]
Looking at the above, perhaps you've misread the code and gave your answer from there? The object does get accessed, but only if it first becomes initialised. So it's not a matter of taking out the second if statement through optimisation process, it's a matter of seeing that the second conditional branch only executes when the first one does.
P.S. In this contrived example, the compiler could even see that on top of that, both if statements always execute, so the statements may as well be extracted into the method block which contains them (I know it's not illustrated but I don't think you can put if statements straight into a class block). But why it doesn't do this , is a second, seperate question unintentionally created by my choice of example.
In my naivity I wrote what I thought was a simplified but accurate example of my actual code without quickly running it. I was wrong. My example code executes without problem. Apparantly the reason it was complaining about potential unitialisation was because within my if statement I was retrieving an object through another class's getter function, but that function itself didn't guarantee I would be returned an initialised object.
I am dully impressed by how thoroughly the IDE checks potential for uninitialised object.