Summary: | Null comparison always yields false warning on an assignment | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Ryan Gross <ryan.gross> |
Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | minor | ||
Priority: | P3 | CC: | eclipse, srikanth_sankaran |
Version: | 3.5.2 | ||
Target Milestone: | 3.6 RC3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Ryan Gross
2010-05-04 15:35:51 EDT
Can you provide a code sample that reproduces the problem and that can actually be compiled? It is not possible to compile or comprehend this incomplete example, so there is no way for us to test or reproduce the problem. By the way, it may or may not be relevant, but I should point out a bug in this code (perhaps this is what the compiler is trying to warn about): if prevHeaderData is null, the first line of the finally{} block will throw a NullPointerException. And, there is no point in setting prevHeaderData to null; it is presumably about to be out of scope anyway (and if it's not, then enclosing that chunk of code in a {} block will have the same effect). All that setting it to null will do is waste a few processor cycles (though hopefully the JIT will optimize it out anyway). If you run Findbugs on this you'll probably get a Dead Store warning. The above is guesswork since I can't see the complete method (nor even the complete loop). Ryan, as Walter pointed out, a working code will help us in figuring out the exact problem, if any. I tried to reproduce the error by using your code and using quick fixes to clean up all the errors. Once I was done, i obtained a null check warning on the first line of the finally block ie. on 'prevHeaderData.dispose();' - Potential null pointer access: The variable prevHeaderData may be null at this location. This warning is expected and correct.(Walter correctly mentions this in comment 2). I, however, could not obtain the warning that you mentioned here. In order to proceed further, I request two things: 1) If possible, can you provide a working error-free code (possibly a minimal piece) that could reproduce this problem? 2) Can you download a newer build and check if you still have the same problem? Thanks! (In reply to comment #0) Sorry, I just noticed that the version is 3.5.2. I'd tried on 3.6. So yes I could reproduce this on 3.5.2, but since its fixed in 3.6, can you upgrade to 3.6? Ryan, let me know if its a problem. Thanks! Closing as WORKSFORME. 3.5.2 development is closed and so this cannot be fixed on 3.5.2 Ryan, you can do either of the two: 1) Download a new 3.6 build. 2) Disable the redundant null check warnings in the Preferences->java->compiler->"errors/warnings"->unnecessary code section. Verified for 3.6RC3 using build I20100527-1700 The code now shows the correct aerror message now |