Github user ahgittin commented on a diff in the pull request:
https://github.com/apache/incubator-brooklyn/pull/506#discussion_r24322893
--- Diff: api/src/main/java/brooklyn/basic/AbstractBrooklynObjectSpec.java
---
@@ -121,4 +121,21 @@ protected final void checkIsImplementation(Class<?>
val, Class<? super T> requir
if (Modifier.isAbstract(val.getModifiers())) throw new
IllegalStateException("Implementation "+val+" is abstract, but must be a
non-abstract class");
}
+ @Override
+ public boolean equals(Object obj) {
+ if (obj==null) return false;
--- End diff --
i don't think it breaks the contract of hashcode -- if a spec is modified
in such a way that the hashcode changes, then the equality semantics will have
changed in the expected way.
as we already have `Object.equals/hashcode` i think this implementation is
an improvement, and putting things into a test convenience would just make
things harder to find.
making the spec immutable would be the elegant way to solve this; i
wouldn't be strongly opposed although i don't see any major benefit at this
time for the extra code. (is spec mutability confusion really a problem?)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
