You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2008/01/31 04:57:17 UTC
UIMA java objects which implement MetaDataObject, question about
equals and hashCode
Many UIMA framework objects implement the MetaDataObject interface.
This interface has an equals method, which does a attribute by attribute
equals check (recursively).
This interface, however, doesn't implement the hashCode method.
So, if any object were to insert one of these objects into a hash table,
two "equal" objects could get different hash codes.
For instance, TypeOrFeature instances implements the MetaDataObject. It
might be stored in a hash table or hash set (this was done in the
previous impl of ResultSpecification _impl).
Wouldn't this (at least in principle, theoretically) cause a problem?
Is the general, safe, fix to add a hashCode method to the MetaDataObject
interface and impl?
-Marshall
Re: UIMA java objects which implement MetaDataObject, question about
equals and hashCode
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally wrote:
> On Jan 31, 2008 11:09 AM, Thilo Goetz <tw...@gmx.de> wrote:
>
>> I think what Adam means is that java.lang.Object implements both
>> hashCode() and equals() anyway, so declaring them on any interface
>> makes no difference (because any class will implement it by virtue
>> of inheritance from java.lang.Object).
>>
>>
>
> Yes, thanks for translating. ;) All objects implement hashCode() and
> equals(). There's no way to force them to do it intelligently. :)
>
> -Adam
>
Thanks for clarifying ;-) There perhaps is a way to encourage
intelligent implementations. Many quality tools (Eclipse refactorings,
Findbugs, for instance) do/can check if some class implements equals
(thereby making it a reasonable assumption that they're overriding the
default impl in Object) without also implementing hashCode; and it
would seem reasonable to signal an warning (which is what the Eclipse
refactoring code did) when it found one without the other.
-Marshall
Re: UIMA java objects which implement MetaDataObject, question about equals and hashCode
Posted by Adam Lally <al...@alum.rpi.edu>.
On Jan 31, 2008 11:09 AM, Thilo Goetz <tw...@gmx.de> wrote:
> I think what Adam means is that java.lang.Object implements both
> hashCode() and equals() anyway, so declaring them on any interface
> makes no difference (because any class will implement it by virtue
> of inheritance from java.lang.Object).
>
Yes, thanks for translating. ;) All objects implement hashCode() and
equals(). There's no way to force them to do it intelligently. :)
-Adam
Re: UIMA java objects which implement MetaDataObject, question about
equals and hashCode
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> Adam Lally wrote:
>> MetaDataObject_impl already implements hashCode. The MetaDataObject
>> interface, though, explicitly declares equals() but not hashCode().
>> This doesn't actually have any effect on the behavior (declaring these
>> on the interface doesn't actually force anyone to override the method
>> if they implement the interface). But it does seem inconsistent from
>> a documentation perspective - either we should declare neither method
>> or both. Really I could go either way. The upside of declaring them
>> is to document that equals and hashCode should be overridden by any
>> implementation of MetaDataObject. The downside is that people might
>> think this is actually enforced by Java, when it is not.
>>
> Are you saying that if the interface you say your class implements has
> "hashCode", but your implementation doesn't implement it, and neither do
> any of your superclasses, that this won't be caught as a compile error
> by Java? or just that you don't have to implement it directly in your
> class? (this I understand). If it just the latter, then it seems to me
> quite valuable to include this in the interface, in case someone says
> they implement it but don't have your implementation of
> MetaDataObject_impl in their superclass path (unlikely, I know...).
I think what Adam means is that java.lang.Object implements both
hashCode() and equals() anyway, so declaring them on any interface
makes no difference (because any class will implement it by virtue
of inheritance from java.lang.Object).
--Thilo
Re: UIMA java objects which implement MetaDataObject, question about
equals and hashCode
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally wrote:
> MetaDataObject_impl already implements hashCode. The MetaDataObject
> interface, though, explicitly declares equals() but not hashCode().
> This doesn't actually have any effect on the behavior (declaring these
> on the interface doesn't actually force anyone to override the method
> if they implement the interface). But it does seem inconsistent from
> a documentation perspective - either we should declare neither method
> or both. Really I could go either way. The upside of declaring them
> is to document that equals and hashCode should be overridden by any
> implementation of MetaDataObject. The downside is that people might
> think this is actually enforced by Java, when it is not.
>
Are you saying that if the interface you say your class implements has
"hashCode", but your implementation doesn't implement it, and neither do
any of your superclasses, that this won't be caught as a compile error
by Java? or just that you don't have to implement it directly in your
class? (this I understand). If it just the latter, then it seems to me
quite valuable to include this in the interface, in case someone says
they implement it but don't have your implementation of
MetaDataObject_impl in their superclass path (unlikely, I know...).
> -Adam
>
>
Interesting observations... Eclipse pointed out to me that there was an
issue of some kind here, when I asked it to implement the equals and
hashCode methods for the new inner class in ResultSpecification. It
said that the TypeOrFeature had an issue with hasCode.
>
> On Jan 30, 2008 10:57 PM, Marshall Schor <ms...@schor.com> wrote:
>
>> Many UIMA framework objects implement the MetaDataObject interface.
>>
>> This interface has an equals method, which does a attribute by attribute
>> equals check (recursively).
>>
>> This interface, however, doesn't implement the hashCode method.
>>
>> So, if any object were to insert one of these objects into a hash table,
>> two "equal" objects could get different hash codes.
>>
>> For instance, TypeOrFeature instances implements the MetaDataObject. It
>> might be stored in a hash table or hash set (this was done in the
>> previous impl of ResultSpecification _impl).
>>
>> Wouldn't this (at least in principle, theoretically) cause a problem?
>>
>> Is the general, safe, fix to add a hashCode method to the MetaDataObject
>> interface and impl?
>>
>> -Marshall
>>
>>
>
>
>
Re: UIMA java objects which implement MetaDataObject, question about equals and hashCode
Posted by Adam Lally <al...@alum.rpi.edu>.
MetaDataObject_impl already implements hashCode. The MetaDataObject
interface, though, explicitly declares equals() but not hashCode().
This doesn't actually have any effect on the behavior (declaring these
on the interface doesn't actually force anyone to override the method
if they implement the interface). But it does seem inconsistent from
a documentation perspective - either we should declare neither method
or both. Really I could go either way. The upside of declaring them
is to document that equals and hashCode should be overridden by any
implementation of MetaDataObject. The downside is that people might
think this is actually enforced by Java, when it is not.
-Adam
On Jan 30, 2008 10:57 PM, Marshall Schor <ms...@schor.com> wrote:
> Many UIMA framework objects implement the MetaDataObject interface.
>
> This interface has an equals method, which does a attribute by attribute
> equals check (recursively).
>
> This interface, however, doesn't implement the hashCode method.
>
> So, if any object were to insert one of these objects into a hash table,
> two "equal" objects could get different hash codes.
>
> For instance, TypeOrFeature instances implements the MetaDataObject. It
> might be stored in a hash table or hash set (this was done in the
> previous impl of ResultSpecification _impl).
>
> Wouldn't this (at least in principle, theoretically) cause a problem?
>
> Is the general, safe, fix to add a hashCode method to the MetaDataObject
> interface and impl?
>
> -Marshall
>