Http client API (original) (raw)

Vasiliy Baranov vasiliy.baranov at oracle.com
Mon Aug 20 06:59:08 PDT 2012

On 17.08.2012 14:30, Michael McMahon wrote:

On 09/08/12 19:15, Chris Hegarty wrote:

Michael,

Looking good, some comments. 1) Why the use of CookieManager, rather than CookieHandler? I would expect that CookieHandler would be a cleaner API CookieHandler is a very low level API, which doesn't offer much functionality beyond managing the cookies yourself, which is what you would have to do, if there were no cookie capabilities in the http api. So, I don't know what we would gain from using it. While CookieManager isn't perfect (and we'd like to suggest a few improvements) it is a higher level API that does take care of cookie management with some common policies pre-defined.

java.net.CookieHandler is an abstract class, almost an interface, that represents everything an HTTP client needs to manage cookies. java.net.CookieManager is a concrete implementation of java.net.CookieHandler. At least that is the case in the current java.net.* design.

That said, shouldn't new HttpClient depend on the more abstract java.net.CookieHandler, rather than the more concrete java.net.CookieManager, for the sake of API cleanness and extensibility? If one prefers java.net.CookieManager over java.net.CookieHandler, it is possible to use the former everywhere where the latter is expected, but not the other way around.

As a side note, in the plugin environment, it might be more natural and less invasive to interface the browser cookie store via java.net.CookieHandler rather than java.net.CookieManager. FWIW, the current plug-in implementation, com.sun.deploy.net.cookie.DeployCookieSelector, does extend java.net.CookieHandler.

Just my two cents.

Thank you, -- Vasiliy

More information about the net-dev mailing list