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

score 4 · Answer 1 · answered Sep 20 '13 at 15:21

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.

This is a great answer, but I wonder if it only applies to Android. They aren't using the same (Oracle) JVM that others use, right? — dhalsim2, Apr 22 '15 at 00:30

score 4 · Accepted Answer · edited May 23 '17 at 12:19

4

The things drive me to Apache HttpClient are,

Buggy keep-alive support.
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.

edited May 23 '17 at 12:19

Community

1
1

answered May 17 '10 at 19:07

ZZ Coder

74,484
29
137
169

What do you mean by buggy keep-alive? can you be a little more specific? Thanks for the answer! – Pablo Fernandez May 17 '10 at 19:15
Let me see if I get this. The problem is that if you do not read the whole stream the following connection gets garbage (unread data) from the first one? This happens because some Stream-sharing between URL Connections? Thanks ZZ – Pablo Fernandez May 17 '10 at 20:08
And how this relates keep-alive? – Pablo Fernandez May 17 '10 at 20:09
If you use keep-alive, all these things cause next connection to fail. – ZZ Coder May 17 '10 at 20:23
...ok you're not much of a talker aren't you? :) Anyways thanks for the answer and for sure is the accepted one! +1 – Pablo Fernandez May 17 '10 at 21:00

Stephen C · Answer 3 · 2014-09-27T00:40:19.787

... 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.

That's the reason why @deprecated got invented. – Pablo Fernandez May 19 '10 at 19:26 — Pablo Fernandez, May 19 '10 at 19:26

httpURLConnection vs apache commons http

3 Answers3