Bugzilla – Full Text Bug Listing
| Summary: | [hashcode/equals] @Nullable final field leads to compilation error in auto-generated hashcode and equals | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Benoit Lacelle <benoit.lacelle> |
| Component: | UI | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | srikanth_sankaran, victor.noel |
| Version: | 4.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
Stephan, thanks for following up. The problem is even that since the fields are final, once their non-nullness has been tested, they shouldn't be considered potentially null! (In reply to Victor Noël from comment #2) > The problem is even that since the fields are final, once their non-nullness > has been tested, they shouldn't be considered potentially null! In the current implementation 'final' is deliberately not considered by null analysis. For further reading cf. bug 484570 comment 3. Regarding the original request: (1) warnings about redundant null checks are correct for @NonNull fields. We might, however, consider not generating these checks for @NonNull fields. (2) warnings regarding potential null pointer access result from (deliberate) lack of flow analysis for fields. Even when enabling syntactic null analysis for fields, the same warnings are raised, which could be fixed by trivial code modifications (invert "?:", change order of if;s). Moving to JDT/UI to consider adjusting the code patterns when fields have null annotations. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |
I consider the following class with a nonnull final field and a nullable final field: public final class URLWrapper { @Nonnull public final String url; @Nullable public final String userAgent; public URLWrapper(@Nonnull String url, @Nullable String userAgent) { this.url = url; this.userAgent = userAgent; } @Override public int hashCode() { final int prime = 31; int result = 1; result = prime * result + ((url == null) ? 0 : url.hashCode()); result = prime * result + ((userAgent == null) ? 0 : userAgent.hashCode()); return result; } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (getClass() != obj.getClass()) return false; URLWrapper other = (URLWrapper) obj; if (url == null) { if (other.url != null) return false; } else if (!url.equals(other.url)) return false; if (userAgent == null) { if (other.userAgent != null) return false; } else if (!userAgent.equals(other.userAgent)) return false; return true; } @Override public String toString() { return "URLWrapper [url=" + url + ", userAgent=" + userAgent + "]"; } } The issue is the hashcode and equals method has been generated by eclipse and it leads to a compilation error "Potential null pointer access: The field userAgent is declared as @Nullable ..." I guess the null analysis should consider the autogenerated hashcode and equals as valid code. Thanks