A DESCRIPTION OF THE REQUEST :
There are many cases where an  customer  reference gets inadvertently assigned to itself (see example).  There is no reason whatsoever for the programmer doing this, since it is an ineffectual operation.  Therefore, the operation almost always causes a bug.  In IDE's such as Eclipse, this produces a complie warning.  Based on the scope of the variable, the compiler could eliminate this problem entirely by recognizing this as a compile error.

JUSTIFICATION :
I have seen an unusually large number of bugs of this type produced by developers who, in general, ignore compile errors that may or may have not been produced by their particular IDE.  While there are workarounds such as alternative naming conventions, reconfiguring an IDE to mark this as an error, etc., making this an error would absolutely prevent programmers from making this common mistake, thereby reducing bugs in general.  I have never seen an occurrence of self-assigning an  customer  reference that was intentional and can't imagine any reason for doing so.  Yes, it would break existing code, but only a) bugs or b) ineffectual lines of code.  Just flip on this option in Eclipse to regard this as an error in any very large Java project and you will likely find several bugs.  IMHO, this should always be a compile error produced by the JDK.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A compile error stating that the assignment has no effect.
ACTUAL -
Nothing, although some IDE's such as Eclipse produce a compile warning.

---------- BEGIN SOURCE ----------
// Example.java
public class Example {
    private int foo;
    public void setFoo(int foo) {
        foo = foo; // assignment has no effect due to improper scope
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Alternative naming conventions, or reconfiguring an IDE to mark this as an error.  However, these are proactive solutions that developers in general don't follow.
Posted Date : 2007-07-18 22:07:29.0

N/A

I have some sympathy with the problems caused by the anti-pattern in setFoo, but it is not for the language to start breaking programs when we do not know the cost of fixing them. Reporting self-assignments is a job for tools.

In particular, it is a job for tools because aliasing makes it Really Hard to know the effect of an assignment in general. Heuristics and formalisms to understand aliasing are proposed all the time in the research community. A toy example that would not be caught by a syntactic rule:
  void setFoo(Object foo) {
    Object foo2 = foo;  // Alias x for some reason
    foo = foo2;  // This assignment has no effect. Should we give an error?
  }
Posted Date : 2007-07-20 18:19:39.0

I do agree that making this a compile error will break existing Java programs.  However I believe the effect would be one of either:  1) Signifying an existing bug or 2) Signifying dead code.  Your example to me is outside of the scope of what I'm suggesting, as you mention it would be too difficult to know the effect or the programmer's intention.  Setting x = x, however in a single operation is always either a bug or dead code.  The cost of savings in fixed bugs could greatly outweigh the cost of fixing those bugs.  Although some people might certainly get angry that their code doesn't compile with a new JDK, this is one case where they are more likely to celebrate finding that pesky bug that's been unknowingly breaking their system for 5 months (Ok, so maybe I'm exaggerating a little, but you see my point).

Anyhoo, if no one else thinks this is important, I'll just keep setting my Eclipse environment to flag it as an error, and suggest others do the same.  But I suspect a quick study of some large codebases might reveal it to be worth the compiler modification.