HttpClient is difficult to implement (even on top of another library, e.g. OkHttp).
⇨ the “okclient” sub-package of our experimental code contains some draft
implementation of HttpClient on top of OkHttp. See the “FIXME” comments
throughout that package for particular issues we ran into where the APIs
couldn’t be adapted to one another.

Some concrete issues:

- Some HttpClient methods could have convenience implementations, e.g. send()
  could have a convenience implementation on top of sendAsync(), or vice versa.

- Optional<CookieManager> HttpClient.cookieManager should probably be a
  Optional<CookieHandler>? Note that CookieManager.getDefault() returns
  CookieHandler. (Also note that CookieHandler is documented to implement an
  obsolete RFC)

- Redirect: Why is this an enum? This seems to needlessly restrict extensibility of
  the API: For example, (as opposed to Effective Java 1st Edition’s type safe enum
  pattern), it makes it impossible to ever define redirect policies at runtime (e.g.
  based on a list of trusted hosts) because the set of instances is fixed at compile time,

- It implements serializable, which the API may not want to commit to at this point.


This issue has been filed to capture comments raised by tobiast at google dot com, see
http://mail.openjdk.java.net/pipermail/net-dev/2017-July/010872.html