|
| Re: final hashCode() and equals() in CDOObjectImpl, proxies and EMaps [message #1099135 is a reply to message #1098887] |
Sun, 01 September 2013 06:55  |
|
Hi Pavel,
I don't fully understand what you're suggesting. It would be best that you submit a bugzilla and attach a test case that
demos the wrong behaviour and your patch that is supposed to fix it. Please copy one of the existing tests as a start
point and try to use our test models.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 31.08.2013 23:17, schrieb Pavel Vlasov:
> Hello,
>
> I have a model which uses CDOObject reference as an EMap key. For me it is a way to implement association class. When
> I put entries to that map I use proxies with unique identifiers, which are transparently resolved when different
> fragments of the model are put together.
> Everything works perfectly fine except EMap.get(Object) method. The reason for this is that CDO EMap implementation
> used hashCode(). hashCode() is final in CDOObjectImpl and I can't override it and return hashCode of the ID attribute.
> Therefore, while CDOObject complies with the EObject contract - identity-based hashCode and equals, it becomes a
> predicament when it is used as a key in EMap.
>
> My workaround for this was to create a filter class which implements EMap and implement get() and put() methods so
> they don't rely on hashCode(). I think this should be addressed in the framework itself - if EMap key is an instance
> of of EObject then the map should not rely on hash table in get() and put() methods.
>
> Thoughts?
> ---
> Best regards, Pavel Vlasov.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03899 seconds
] 
Search
Help
Register
Login
Home
