Obscure conditional Java Syntax

Question

We just found, a colleague and I, a strange compiling syntax with the If conditional syntax :

if (true); {
  foo();
}

Is there someone here for explaining to us this strange syntax? Thx.

Answer 1

The first part, if (true); is just a do-nothing conditional that ends at the ;. The rest is a call to foo() inside a new scope block. You should find that foo() is always called.

Answer 2

to me, it looks like an if statement with an empty body, followed by a code block that always executes (and is unrelated to the if statement). For example, does foo also execute here:

if (false); {
    foo();
}

Answer 3

i think this is equvalent to

if (true) {};
foo();

since the if statemnt is ended after the semicolon and the foo statement just got placed in a block ({}) ...

Answer 4

Maybe a remain from an old debugging if, or someone was planning to write a condition later but never did it...

I think you can safely remove this if statement, there's absolutely no point in doing this.

Answer 5

That's dead code. The if block is useless.

The equivalent of

if(doesn't matter whats here) {}
foo();

Answer 6

This makes no real sense but is syntactically correct. It could also be written as

if (true) 
{    
    // do nothing 
}
{   
    foo(); 
}

with the {} around foo(); meaning nothing in this case. It would limit the scope of variables defined within the {} if there were variables defined.

{
   int i=0;
   System.out.println(i);
}
{
   String i="hello";
   System.out.println(i);
}

works just fine.

Answer 7

As others have pointed out, syntactically it's a conditional with an empty execution statement (i.e. does nothing) followed by a call to foo() enclosed within scoping brackets. foo() is always executed. In practice, if you found this in a real case and not a programming test I suspect one of the following:

1. It's a misprint, in which case it should be corrected (when you find out what the code should do)
2. It's a deliberately obscure piece of code intended to confuse the reader, in which case it should be fixed (replaced with "foo();") and the perpetrator should be hunted down and reprimanded
3. It was generated by a (poor) automated source code generator, in which case it should be commented to indicate that
4. It's left over from a debugging session, in which case it should be restored to whatever it was before the change was made