"The left hand side of an assignment must be a variable" due to extra parentheses

Question

I know why the following code doesn't compile:

public class Main {
   public static void main(String args[]) {
      main((null)); // this is fine!
      (main(null)); // this is NOT!
   }
}

What I'm wondering is why my compiler (javac 1.6.0_17, Windows version) is complaining "The left hand side of an assignment must be a variable".

I'd expect something like "Don't put parentheses around a method invokation, dummy!", instead.

So why is the compiler making a totally unhelpful complaint about something that is blatantly irrelevant?

Is this the result of an ambiguity in the grammar? A bug in the compiler?

If it's the former, could you design a language such that a compiler would never be so off-base about a syntax error like this?

---

Okay, I just checked and apparently this complaint is only seen from within Eclipse. If I compile from the command line, it gives the more sensible "Not a statement" error. The mystery deepens.

Answer 1

Your version must be wonky. :-P When tested on OpenJDK (as distributed with Ubuntu 9.10), this is what I get:

ParensTest.java:4: not a statement
        (main(null));
        ^
1 error

---

Update based on OP's edit: Eclipse uses its own Java compiler, called ecj; it does not use the JDK compiler (javac). That is why you get different output sometimes. (And yes, the bytecode generated is sometimes different too, causing funky differences in behaviour depending on whether you compiled your code in Eclipse.)

(As an aside, another difference between ecj and javac in my experience: javac will tell you to get lost if you have a string constant over 65535 bytes long (this is a limitation in the class file format). ecj will actually try to emulate such a long string constant, by piecing together shorter parts, each fitting within the 64k limit, with a StringBuilder, then finally interning the result---just as would happen with a "real" string constant.)

Answer 2

Java compiler messages are generally very unhelpful. They only really make sense to compiler writers.

From a parser perspective, it gets an expression and gets to the point where the only legal thing left to do is assign it to a variable, and there isn't one, so it gives up.

Could you design more helpful compiler messages? I suppose, but I doubt Sun/Oracle would regard that as a high priority.