Community
Participate
Working Groups
HEAD Various bugs in "Comparing identical operands" problem detection: public class Snippet { int f; public static void main(String[] args) { if (args == args) // OK System.out.println(0); if (true == true) // missing warning System.out.println(1); if (1 == 1) // missing warning System.out.println(2); if (1L == 1.0) // missing warning System.out.println(3); if (1 + 2 == 1 + 2) // missing warning System.out.println(4); if ((args == null) == (args == null)) // missing warning System.out.println(5); int a= 12; int b= 13; if (a + b == a + b) // missing warning System.out.println(6); if (a < a ) // missing warning System.out.println(7); if (a <= a ) // missing warning System.out.println(8); new Snippet().concurrency(args); } void concurrency(String args[]) { Snippet s= new Snippet(); if (this.f == this.f) // couldn't field f be changed in parallel // by another thread? System.out.println(11); if (s.f == s.f) // why different from (this.f == this.f)? System.out.println(12); if (args.length == args.length) // why different from (this.f==this.f)? System.out.println(13); } }
> if (args.length == args.length) // why different from (this.f==this.f)? Actually, there's no potential concurrency problem here (length is immutable). It might also be worthwhile to split this up into 2 problems, like the null access problems: - One for definitively unnecessary code (I would set this to error), and - one for equal expressions like (a.hashCode() == a.hashCode()), which is only a potential programming problem, due to side effects or concurrent access
Currently, it is only considering obvious issues. More advanced cases are not to be considered. It is simply a reuse of the code telling about assigning a variable to itself.
If this is not going to be improved for 3.5, then - JDT/Core should mention in the Javadoc of JavaCore.COMPILER_PB_COMPARING_IDENTICAL that it currently only detects comparison of identical variables, and - JDT/UI should make this clear in the UI (change setting to "Comparing identical variables")
It could be improved still, I think most of your samples are valid expectations.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
