views:

109

answers:

2

Hi everyone!

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

+4  A: 

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,

http://stackoverflow.com/questions/1440957/httpurlconnection-getresponsecode-returns-1-on-second-invocation

http://stackoverflow.com/questions/2792843/httpurlconnection-whats-the-deal-with-having-to-read-the-whole-response/2792924#2792924

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

ZZ Coder
What do you mean by buggy keep-alive? can you be a little more specific? Thanks for the answer!
Pablo Fernandez
See my edits ........
ZZ Coder
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
And how this relates keep-alive?
Pablo Fernandez
If you use keep-alive, all these things cause next connection to fail.
ZZ Coder
...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
A: 

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

Stephen C
That's the reason why @deprecated got invented.
Pablo Fernandez