Are you sure if (true) is an oxymoron? It is redundant code, anyway.
The compiler is not programmed to be stupid, but there are restrictions on how one can program compilers. If for example one wishes to go through the code for changes to variables, one can tell [just by looking] that this if block will never be entered; But the performance overhead of [using a compiler for] siuch checking for such changes, in order to confirm that the block can never be entered would make compilation slower than writing the code, especially if there is much code between the declaration and that if. Now, marking i final, so it is a compile-time constant, that might change things. The compiler designers obviously came to the decision that such checking is feasible, but, “life’s too short.”
If you permit break; statements, then while (true)... is valid code, so why not if (true)?
[Edit]Add two short bits of text in [blue print] above[/edit]
The correct reason is the one Martijn gave and Matthew posted a JLS link confirming. I suggest reading that link. A valid Java compiler is required to behave this way, treating "if (true)" as if it's something that may evaluate to false, even though it's obviously going to be true. Some IDEs like Eclipse may choose to perform a different (perhaps more sensible) analysis - but they can only issue warnings; they can't prevent compilation here. Not without violating the JLS.
It was the best of times. It was the worst of times. It was a tiny ad.
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps