Skip to main content

The Better Compiler the Worse API!?

Posted by jst on October 16, 2008 at 12:03 PM PDT

Today I am ready to announce a really nice addition to the collection of weird examples of APITypes. Did you ever suffered with compiler optimizations? Did you ever thought about them as being an example of an API?


It is always easier to explain why there is a problem, if we know what the problem is. The "surprises" comes from discovering the root of problem, not explaining it... "some other errors" - indeed, there are also other errors, as in every code. "explanation of some various problems" - FolderChildren has been heavily affected by the clash between programmers vs. compiler understanding of what a piece of code shall mean. "what is surprising" - surprising is that it took years to find out what is wrong. ""compiler will give you an error" - the compile would give you error, if someone modified the code, however many people looked at the code (U2) and none envisioned the problem.

I do not see what is so surprising in your example - retValue cannot be used after that if block and compiler will give you an error (variable ... might not have been initialized). So there is no reason to treat its value as a reachable object. The conclusion in next paragraph that this can be an explanation of various hard-to-understand problem seems weak to me. I'd bet that there are some other concurrency errors involved.

Thanks for your comments. I've updated the page to reflect them.

" however the consequences of my finding are really horrible" Can you explain, for the ones that do not understand why a variable shouldn't be reclaimed even when it's obviously not used, and particularly what exactly the horrible part is? And no, compiler optimizations are all but apis. You can't depend on them, and if you do depend on undefined implementation details (as probably do the broken tests you referred), the behavior of your programs is indeed undefined.

I have been burned by this before. It (among other things) led me to declare as much of my code as I possibly can as final--including local variable assignments. Instead of: String foo = null; if (someCondition) { foo = "argh"; } // do something with foo ...I'll do: final String foo; if (someCondition) { foo = "argh"; } else { foo = null; } // do something with foo ...obviously only in cases where the extra verbosity is worth it. Best, Laird

Hey Jarda, that's pretty strange. Oh, and welcome to!