The HttpUrlConnection is from the
standard Java SE API and HttpClient is a
Apache Commons library which is built
on top of the standard Java SE one. Apache Commons libraries in turn are usually more
convenienced and less opaque (read: less low-level).
In fact,
everything can be done with the
standard
Java SE API. Major goal of those kind of libraries are just faster
development and lesser code. In this particular example you can for
instance send a POST request with just one or two HttpClient methods
instead of writing 10~20 lines of code as you would do with plain
HttpUrlConnection
. The same story applies on the Apache Commons IO v.s.
java.io
and Apache Commons Lang v.s.
java.lang
, Apache Commons Collections and Google Collections v.s. Java Collections, etcetera.
Features Comparison :
Explanations
[unsupported] - This feature exists in this release,
but may not be supported in future releases.
idle connection timeout - Most servers timeout connections
after a certain interval. When HTTP clients use connection pooling,
the fact that the connection was closed is detected when the next
request is written to the connection. If it's an idempotent request
(like a GET, or PUT) then it can just be retried on a new
connection. However, POST cannot be retried (we don't know if it
has been processed by the server or not),
so the user of the HTTP client will get
an error on this POST. The Oakland Software implementation provides a
facility to terminate connections which have been idle for a
(configurable) length of time, or alternatively to send a "ping"
message before using a connection (if it has been idle for a certain
amount of time). This ensures that POST requests will not be
affected by the server connection timeout processing.
pipelining of requests - This allows multiple requests to be sent
on the same connection before getting the response to the first one.
This can make a tremendous performance difference when fetching
many objects from the same server (as you don't have to pay the
round trip latency for each request). This can also make a substantial
throughput difference when in high volume applications by reducing
the latency and sharing the socket connections for multiple requests
at a time. The Oakland Software pipelining implementation is the only
implementation that automatically
handles all authentication modes before starting pipelining, allows
pipelining for POST (useful in certain controlled environments), and
automatically adapts to the server closing connections for maximum
pipelining performance.
non-blocking I/O - In most HTTP implementations, the outstanding
HTTP request ties up a thread until it is completed. This restricts
the number of outstanding HTTP requests to the number of possible threads,
which is a significant limitation (since each thread consumes a certain amount
of memory). With non-blocking
I/O the request can be sent and the response can be received on a different
thread, thus an unlimited number of outstanding connections can be active
with a small number of active threads.
This support is useful for applications where large numbers
of connections must be processed quickly. This (especially combined
with pipelining and the use of direct reading and writing from
the socket) give maximum throughput.
connection pool throttling - This is
very useful in certain server situations.
This is a limit on the number of connections to a given host and
port. The HTTP 1.1 specification recommends that no more than 2
connections are established (to a given host/port).
In any of the other implementations
(that use connection pooling) it will open as many connections as
you have requested. This can cause problems for some servers.
connection request timeout - A good timeout mechanism has
three parts: timeout when establishing the initial connection,
setting the TCP timeout on the connection (so that each request is
subject to the timeout), and, if connection pooling is used, timeout
while waiting for a connection to be available from the pool. The
Oakland Software implementation is the only implementation that supports all
of these.
true request/response streams - The older JRE implementations by default
record the request data into a byte array and does
not actually send the data until the connection is open. This
results in double copying of the data, resulting in slower
performance in cases where there is a lot of data. Other
implementations allow you to read/write directly to the underlying
connection stream, avoiding this double copy of the data. It also
avoids reading this data if not required by the application, which
is not possible if there is not a true response input stream.
After JRE 5, direct streaming to the output was implemented by adding
new methods (setChunkedStreamingMode() and setFixedLengthStreamingMode())
however, these methods will not work if the connection requires
authentication. The Oakland Software implementation will perform the
authentication automatically before beginning the streaming processing
so streaming works transparently with authentication.
NTLM - The JRE 1.4.2 supports NTLM only on Windows. The Oakland
Software and Apache HTTP clients support NTLM on any platform.
However only the Oakland Software NTLM support correctly supports
both Unicode and OEM encoding for NTLM and supports NTLM V2.
The Sun implementation in JRE 6 and 1.5_08 and higher support
NTLM V2 on all platforms, though on Windows they use the current user's credentials
by default.
plug compatible - This is true if you can switch to this HTTP
Client from the Sun HTTP client without changing any code and it
will just work. This means the HTTP Client implements the
java.net.HttpURLConnection class, and the necessary protocol
handlers for HTTP and HTTPS.
versions - JRE versions prior to 1.2.x and 1.3.x are supported only with
version 1.x of the Oakland Software HTTP client. This includes
all of the features except pipelining and Axis2 support. Version 2.x and
higher of the Oakland Software HTTP client require JRE version 1.4.2 or higher.
slow turnaround - You get fixes to the Sun HTTP Client when a
new version of the JDK is released, which is usually a long wait.
fast turnaround - Considering the Oakland Software product is actively
supported, and support contracts are available, fixes can be released as
fast as next day and usually within a week.
medium turnaround - The Apache HTTP Client is supported as
there are volunteers to work on it. Currently they offer pretty
quick support, so long as you are willing to take their nightly
builds. There have been periods though where no one was working on
it, and this could be the case again. You can't be sure, but you
can fix it yourself if you want.