HttpClient vs. Jigsaw vs. HTTPClient

[Gunnlaugur Thor Briem <gt...@dimon.is>]

Hi HTTP client-side implementation buffs,

here come the questions nobody finds all that fun,
but I couldn't find them answered elsewhere, and I
believe it is valuable to try to answer them (and
also to publish the answers somewhere visible!)

In fact I was surprised to see that a full-text search
of the commons-dev@jakarta.apache.org archives at
http://marc.theaimsgroup.com/ revealed not a single
occurrence of the word "jigsaw"!

I've found three open-source Java implementations of
the client side of HTTP:

	Jakarta Commons HttpClient
	http://jakarta.apache.org/commons/httpclient/

	Ronald Tschalär's HTTPClient
	http://www.innovation.ch/java/HTTPClient/

	the W3C Jigsaw HTTP client implementation
	http://www.w3.org/Jigsaw/
	(packages org.w3c.www.http and
	org.w3c.www.protocol.http and subpackages)

Here are my very preliminary findings:

- The third has a nice extensible design (pluggable
filters acting before and after connections, and
caching, authentication and cookies are implemented
using that framework, and also it abstracts all
standard HTTP headers in classes) and comes from an
authority one would assume could be trusted to write
a compliant implementation :) [though the Apache
community certainly gets such trust by default as
well ... Ronald Tschalär is less known, no offense,
so the *default* trust is less], but after I bumped
into the capital crime of a System.exit(1) in the
code (and then found 17 more System.exits with a
quick search) I am not thrilled about it; it may be
HTTP-compliant, but it apparently doesn't comply
with general Java prudence! :) But that might just
indicate that a quick cleanup job is in order.

- The second doesn't support HTTPS, though there
are "patches" for it here and there that add such
functionality.

- The first and second apparently don't include any
caching functionality (am I wrong here?)

- The first is clearly the project most oriented
towards the participation of arbitrary developers from
remote corners of the Earth such as myself :) by
virtue of the existing Jakarta infrastructure for
open-source development.

But I have no idea about relative performance,
compliance, and quality levels (bug proliferation)
among these implementations. Google failed me in
finding any references online. Investigating this
myself by testing each will be a hefty job, so I
hope to lighten it by asking ...

(1) has someone involved in one of these projects
looked at the other two at all, for purposes of
comparison in terms of compliance, performance and
general level of maturity?

(2) has someone NOT involved with any of these
projects tried out all three and reached some kind of
meaningful conclusions that would be valuable to
others?

I hope I'm not going to provoke any outbreaks of
"my baby is cuter than yours" here, I just feel
that I'm going to need to use one of these
implementations (Sun's HttpURLConnection really
isn't doing it for me, would you believe) and
take part in its development to meet any needs
of my project that aren't already met, and I
want to have some basis for deciding which one
it should be.

Hoping for some interesting responses! If I
get any that are addressed to me and not the
commons-dev mailing list, then I'll send a
single summary to the list.

Thanks,

	- Gulli


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>