httpURLConnection vs apache commons http

Question

I just wanted to know if any of you had any problems using java default HttpURLConnection class. Some kind of bug that made you switch to apache commons.

Or is it just the (ugly) interface that class exposes that justifies the birth of 3rd party http lib?

Disclosure: I heard some arguments against java.net having some serious problems, but I'm finding hard to believe that a class that is part of the java core distribution still has issues after several releases of the JDK

Answer 1

The things drive me to Apache HttpClient are,

1. Buggy keep-alive support.
2. Cookie handling.

You should use HttpClient 4 (Apache HTTP Components) now.

EDIT: The first problem has been discussed several times here. See,

HttpURLConnection.getResponseCode() returns -1 on second invocation

HttpURLConnection: What's the deal with having to read the whole response?

Even though the problem seems to be worse on Android, we saw the exact problems on J2SE.

Answer 2

The Android SDK says Prefer HttpURLConnection for new code.

Android includes two HTTP clients: HttpURLConnection and Apache HTTP Client. Both support HTTPS, streaming uploads and downloads, configurable timeouts, IPv6 and connection pooling. Apache HTTP client has fewer bugs in Android 2.2 (Froyo) and earlier releases. For Android 2.3 (Gingerbread) and later, HttpURLConnection is the best choice. Its simple API and small size makes it great fit for Android. Transparent compression and response caching reduce network use, improve speed and save battery. See the Android Developers Blog for a comparison of the two HTTP clients.

Answer 3

... but I'm finding hard to believe that a class that is part of the java core distribution still has issues after several releases of the JDK.

In defence of Sun, they are caught between a rock and a hard place:

• If they fix these problems they will undoubtedly break tens of thousands of legacy applications that depend on the current APIs and their less-than-ideal behaviour. If they did that, the fallout from their paying customer base would be massive. And more enterprises would be stuck using ancient JDK releases.

• If they don't fix the problem, they get endless flak from purists who think that every problem should be fixed, and damn compatibility.

At least people who need a HTTP client API have a better alternative ... should they want to use it.

---

That's the reason why @deprecated got invented.

Theoretically, yes ...

However, in practice, deprecation is used by Oracle as a strong signal to programmers (and more importantly, managers) that they need to change their code.

That is not warranted here. Lets look at the concrete issues:

• "HttpURLConnection cannot handle cookies" is not a reason to deprecate it. People who have already built applications against HttpURLConnection will have already dealt with this issue. For them, changing to a different HTTP client class unnecessary work.

• "HttpURLConnection doesn't support keep-alives" is not a reason to deprecate either. Most applications don't need keep-alives.

And so on.

Deprecation is a blunt instrument, and the Sun / Oracle philosophy is that it should only be used in cases where an API is difficult to use safely; i.e. when there is a strong business case for developers spending time in reworking code, etcetera.

But don't just take my word for it. Look at the cases where Sun / Oracle has deprecated methods and classes. There is a clear pattern, even if there are historical exceptions to it.