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. > > 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]
