On 24 April 2014 13:49, Oleg Kalnichevski <[email protected]> wrote: > 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.
Yes but in order to guarantee predictable behaviour the class must also be final. If the class is not final, then users can add a field to the class. In most cases instances of the class then only continue to work properly if hashcode/equals are adjusted to allow for the additional field. I don't think a non-final class with final hashCode/equals methods makes any sense. Either make the class final, or allow the class to be extended (including hashCode/equals) and hope that the sub-class is properly implemented. > 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]
