On 02/02/2009, Oleg Kalnichevski <[email protected]> wrote: > On Mon, 2009-02-02 at 21:03 +0000, sebb wrote: > > On 02/02/2009, Oleg Kalnichevski <[email protected]> wrote: > > > sebb wrote: > > > > > > > BasicHttpRequest currently has a non-final field "requestLine". > > > > > > > > This could be made final, and the check/update of the field in > > > > getRequestLine() removed, as the field cannot be null. > > > > > > > > S/// > > > > > > > > > > > > > > Hi Sebastian, > > > > > > The reason for this variable being non-final is to make it possible to > > > mutate HTTP protocol version of an existing BasicHttpRequest through the > > > HttpParams collection associated with the object. > > > > However, there is actually no way to change the private variable - > > there is only a getter, and no setter - so other classes cannot change > > it. > > > > > True. But its initialization is deferred until the #getRequestLine() > method is called for the first time.
Duh! - sorry, I missed that the construction of the object fetches the version, which of course can be changed after the original object was created. Finally I understand it (I hope). But that applies only if the following constructor is used: BasicHttpRequest(final String method, final String uri) The other two constructors set it non-null anyway. > Besides, even if the variable was final, the class would still be > threading unsafe, as its sub-class (AbstractHttpMessage) is not. I think you mean super-class, but agreed, it does not make the class thread-safe. I withdraw the suggested fix, but I think some documentation is needed to explain why the field is not initialised in the constructor. > > Oleg > > > > > > It is basically a hangover > > > from the 3.x days. I do not mind changing the behavior and making the > > > variable final. > > > > Great! > > > > Though in fact it won't change the behaviour, as mentioned above. > > > > Sebb > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
