On 23 April 2014 16:59, Oleg Kalnichevski <[email protected]> wrote: > On Wed, 2014-04-23 at 14:19 +0400, Dmitry Potapov wrote: >> On Wed, Apr 23, 2014 at 11:55:33AM +0200, Oleg Kalnichevski wrote: >> > On Tue, 2014-04-22 at 15:55 +0400, Dmitry Potapov wrote: >> > > Hello, everyone, >> > > >> > > I have list of HttpHost which is use for requests fallback. I've decided >> > > to >> > > assign some weight for this hosts, to use more reliable for requests and >> > > fallback to less reliable in case of failure. >> > > Most obvious solution is to extend HttpHost with class that supports >> > > weight and >> > > provides compareTo() function, so I can sort this list each time the >> > > weights >> > > are changed. Unfortunately, I've found that HttpHost is declared final >> > > and >> > > can't be extended. >> > > What is the reason for such restriction? If there is no one, then can we >> > > remove >> > > it? >> > > >> > >> > Dmitry, >> > >> > HttpHost is used as a part of route info used as a map key by connection >> > managers. A subclass of HttpHost with incorrectly implemented >> > #hashCode / #equals can mess up connection pooling. >> Incorrect implementations of #hashCode / #equals can mess up everything. >> IMHO, nobody will override them without reason. > > You'd be amazed. > >> If you're insisting on your implementation of these functions, what about >> make final only these two functions, not the whole class? >> > > > I could certainly live with that but Clirr reports making #hashCode / > #equals final as breaking binary compatibility despite the fact that the > whole class was final. I cannot really say whether or not the complaint > is merited, but would still prefer to keep Clirr happy.
I don't know why Clirr complains. But if a class is extended and any fields are added, hash/equals will need to be adjusted accordingly. So in general it does not make sense to have a non-final class with final hash/equals, as that places very strict limits on what subclasses can safely add. And of course HC would have no control over such sub-classes. > >> > Would not it be cleaner to use association instead of inheritance in >> > this particular case? >> This was my thought, but since all other facilities relies on lists of >> HttpHost >> objects, this will make code less clear. Additional objects construction >> doesn't worth single attribute attaching to the HttpHost object. >> > > > I could imagine adding an instance variable to the class enabling an > arbitrary object to be added as an attachment to class instances. It is > not pretty but would save you one allocation on the heap per HttpHost. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
