Hello again! I've done a bit of http client use so I have a few suggestions:
* UrlConnection IS effectively deprecated (like Date) - I think everyone's on board here... if not:
this is the reality of the Java library - old API's don't die, aren't deprecated, they just linger and are not improved
There was no interest in adapting UrlConnection to NIO or NIO.2 at JavaOne '08, I asked
Do not use UrlConnection as a fallback/excuse for prohibiting a feature
but you don't have to implement absolutly everything, just provide empty protected methods which allow the user to implement these (Proxy, Cert handling, and such)
* Jetty's Future-based interface is very nice for user-end code. There are some essential services that I feel client implementers may think are missing
CompletionService support is absolutely essential
single-in multiple-out (first responder wins input fight) for a shared Future without wasting resources (from Paul's assessment is this the Jersey inefficiency? wasted threads?)
implementers will want non-blocking offer directly on the Future
I've done some legwork in this direction and have generalized how Future.cancel() can callback to the IO API to free resources (yes that means the first user to cancel a shared future cancels all, like deleting from an Iterator affects the list)
* intermediate progress support for extreme user feedback
protected void connectionProgress(String property, int value) {
}
this will let Swing programmers write their own AsynchUrlConnectionSwingWorker
* for get(Class<T> c) I was going to suggest some specific required implementations (javax.transform.Source) but maybe just provide an overridable factory
-karl