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 <[email protected]> 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 > [email protected] > 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 > > > > >
