You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Holly Cummins <cu...@uk.ibm.com> on 2011/05/08 19:00:15 UTC
Behaviour of == and equals() on blueprint proxies
Hi all,
I've hit another piece of behaviour which surprised me. If I perform
operations on an injected service, I see the following behaviour for ==
and equals()
thing == thing -> true (reassuringly)
thing.equals(thing) -> false (unexpectedly!)
What's going on is that when equals is called, the proxy delegates to the
'real' object, which doesn't have an implementation of equals(). The real
object does an == check, compares itself for identity with the proxied
object. These two objects aren't == identical, so equals() returns false.
One workaround is to implement equals() on my service objects, but it
doesn't feel right that users have to implement equals() just for
thing.equals(thing) to return true.
The other option is that our proxy implementation could special case
equals, and do an == check before delegating to the 'real' object if the
answer is false. Not only would this give more consistent equals()
behaviour, it might also give a slight performance win.
Opinions?
Holly
--
Holly Cummins
OSGi Applications
Desk DE3B18, MP 211,
IBM Hursley, UK
cumminsh@uk.ibm.com
Phone: External +44 (0) 1962 815104 ; Internal 7-245104;
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Behaviour of == and equals() on blueprint proxies
Posted by Andreas Pieber <an...@gmail.com>.
+1; This idea sounds reasonable to me
Kind regards,
Andreas
On Sun, May 8, 2011 at 7:00 PM, Holly Cummins <cu...@uk.ibm.com> wrote:
> Hi all,
>
> I've hit another piece of behaviour which surprised me. If I perform
> operations on an injected service, I see the following behaviour for ==
> and equals()
>
> thing == thing -> true (reassuringly)
> thing.equals(thing) -> false (unexpectedly!)
>
> What's going on is that when equals is called, the proxy delegates to the
> 'real' object, which doesn't have an implementation of equals(). The real
> object does an == check, compares itself for identity with the proxied
> object. These two objects aren't == identical, so equals() returns false.
>
> One workaround is to implement equals() on my service objects, but it
> doesn't feel right that users have to implement equals() just for
> thing.equals(thing) to return true.
>
> The other option is that our proxy implementation could special case
> equals, and do an == check before delegating to the 'real' object if the
> answer is false. Not only would this give more consistent equals()
> behaviour, it might also give a slight performance win.
>
> Opinions?
>
> Holly
> --
> Holly Cummins
> OSGi Applications
> Desk DE3B18, MP 211,
> IBM Hursley, UK
> cumminsh@uk.ibm.com
> Phone: External +44 (0) 1962 815104 ; Internal 7-245104;
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
Re: Behaviour of == and equals() on blueprint proxies
Posted by Tim Ward <ti...@hotmail.com>.
This is actually fixed in the OSGi 4.3 weaving proxy, and I thought I fixed it in the subclass/JDK proxy code at the same time.
Have you tried a recent version of trunk (i.e. less than 2 weeks old?)
Regards,
Tim
Sent from my iPhone
On 8 May 2011, at 18:00, Holly Cummins <cu...@uk.ibm.com> wrote:
> Hi all,
>
> I've hit another piece of behaviour which surprised me. If I perform
> operations on an injected service, I see the following behaviour for ==
> and equals()
>
> thing == thing -> true (reassuringly)
> thing.equals(thing) -> false (unexpectedly!)
>
> What's going on is that when equals is called, the proxy delegates to the
> 'real' object, which doesn't have an implementation of equals(). The real
> object does an == check, compares itself for identity with the proxied
> object. These two objects aren't == identical, so equals() returns false.
>
> One workaround is to implement equals() on my service objects, but it
> doesn't feel right that users have to implement equals() just for
> thing.equals(thing) to return true.
>
> The other option is that our proxy implementation could special case
> equals, and do an == check before delegating to the 'real' object if the
> answer is false. Not only would this give more consistent equals()
> behaviour, it might also give a slight performance win.
>
> Opinions?
>
> Holly
> --
> Holly Cummins
> OSGi Applications
> Desk DE3B18, MP 211,
> IBM Hursley, UK
> cumminsh@uk.ibm.com
> Phone: External +44 (0) 1962 815104 ; Internal 7-245104;
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
Re: Behaviour of == and equals() on blueprint proxies
Posted by Guillaume Nodet <gn...@gmail.com>.
That sounds like a good idea to me.
On Sun, May 8, 2011 at 19:00, Holly Cummins <cu...@uk.ibm.com> wrote:
> Hi all,
>
> I've hit another piece of behaviour which surprised me. If I perform
> operations on an injected service, I see the following behaviour for ==
> and equals()
>
> thing == thing -> true (reassuringly)
> thing.equals(thing) -> false (unexpectedly!)
>
> What's going on is that when equals is called, the proxy delegates to the
> 'real' object, which doesn't have an implementation of equals(). The real
> object does an == check, compares itself for identity with the proxied
> object. These two objects aren't == identical, so equals() returns false.
>
> One workaround is to implement equals() on my service objects, but it
> doesn't feel right that users have to implement equals() just for
> thing.equals(thing) to return true.
>
> The other option is that our proxy implementation could special case
> equals, and do an == check before delegating to the 'real' object if the
> answer is false. Not only would this give more consistent equals()
> behaviour, it might also give a slight performance win.
>
> Opinions?
>
> Holly
> --
> Holly Cummins
> OSGi Applications
> Desk DE3B18, MP 211,
> IBM Hursley, UK
> cumminsh@uk.ibm.com
> Phone: External +44 (0) 1962 815104 ; Internal 7-245104;
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/