On April 23, 2014 8:44:29 PM CEST, sebb <[email protected]> wrote: >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. > But that is precisely the intent here. The whole point of making #hashCode and #equals is to ensure predictable behavior of connection pools.
Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
