hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Why HttpHost declared final?
Date Thu, 24 Apr 2014 12:49:54 GMT
On April 23, 2014 8:44:29 PM CEST, sebb <sebbaz@gmail.com> wrote:
>On 23 April 2014 16:59, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message