On Tue, 2013-11-05 at 19:37 +0100, Christopher BROWN wrote: > Oleg, > > OK, I did this. I thought that, given that using DefaultHttpClient was > deprecated in favor of using CloseableHttpClient, the API had been changed > to a "build immutable objects for better performance" model, with the > fluent API as a side-effect. > > Is the API still totally or partially mutable then, with a new requirement > to maintain related object instances instead of obtaining them from the > HTTP client instance? > > I've not noticed any significant reduction in lines of code, and it took a > lot of time and searching (despite the hints and tutorial) to rewrite code > such that there were no "deprecated" warnings. > > Thanks, > Christopher >
Christopher The internal implementation of CloseableHttpClient is fully immutable. This makes it significantly easier to ensure its thread safety and also faster. That does not mean though its dependencies must be fully immutable. They just need to be thread safe. There are better ways of managing variable aspects of HTTP request execution than messing with the HttpClient instance, namely by using custom HttpContext instances and per request parameters. The HttpClient instance should be a shared singleton and ought not be changed (or changed often). I am sorry if you do not like the new APIs, but just cannot make everyone happy, can I? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
