hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Why HttpHost declared final?
Date Wed, 23 Apr 2014 18:44:29 GMT
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.

>
>> > 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message