3

Is there a way to configure Eclipse to automatically generate hashCode and equals with awareness of @NonNull annotations? Currently my Eclipse generates the code with unnecessary null checks, even on fields that are marked @NonNull.

Note that FindBugs will raise warnings that these null checks are redundant. Of course we can add @edu.umd.cs.findbugs.annotations.SuppressWarnings("RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE") to the methods, but that seems to undermine the role of FindBugs and @NonNull in the first place.

It looks to me that the best solution is to have Eclipse be aware of JSR 305 and generate equals and hashCode accordingly without null checks (and if they are null anyway then so be it and let a NullPointerException be thrown naturally, because a contract violation has occurred).

Short of that, having a way to customize the equals and hashCode template generated by Eclipse would also be nice.

Related questions

Community
  • 1
  • 1
polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
  • 1
    +1 "have Eclipse be aware of JSR 305" and/or "having a way to customize the equals and hashCode template generated by Eclipse would also be nice" – Bert F Dec 09 '10 at 14:31

1 Answers1

2

I would argue that the those null checks are not unnecessary. If they were left out, then equals and hashcode would misbehave on objects that don't pass validation, and that would cause all sorts of problems.

FOLLOWUP

Then what's the use of @NonNull annotations if you're still going to check for null everywhere anyway?

The point of the annotation is to declare that a valid instance doesn't have a null in that attribute, and allow the validation mechanism to be implemented based on that declaration.

However, nothing requires instances to be valid at all times. Indeed, if that was the case, then you'd run into all sorts of implementation problems (for example) while creating and linking instances together.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 3
    Then what's the use of `@NonNull` annotations if you're still going to check for `null` everywhere anyway? – polygenelubricants Dec 04 '10 at 03:27
  • 1
    I'm with @poly - those field annotations are there to express a constraint in code and make those null checks redundant. At the very least, they should be asserts. If I had a field `private int age` that should always be non-negative and my implementation ensured it is always non-negative, should do I still add checks to everywhere to ensure that my implementation maintained its promise? Should I check every constraint of every ivar at the start of every method? – Bert F Dec 09 '10 at 14:54
  • This folds into the answers/commentary about trusting contracts in http://stackoverflow.com/questions/271526/how-to-avoid-null-statements-in-java/271874#271874, but this is a stronger contract/"promise" since its the design/class-designer making the promise rather than the clients of the class. – Bert F Dec 09 '10 at 14:55
  • That is fine ... until your equals methods start throwing NPEs because you are comparing objects that haven't been validated, or that have failed validation. The @NotNull annotation is a declaration that the field shouldn't be null, not a contract that it won't. If constraint annotations were contracts, then it would be unnecessary to call Validator.validate ... ever. – Stephen C Dec 09 '10 at 21:23