OK, it was just an idea! Thanks for taking the time to consider it anyway.
Turning the problem on its head, it seems like HttpClient 4 is intended to be a really complete package... Are there any features that aren't intended for say HttpClient 4 that might be implemented in HttpClient 5 (that you've already thought of) ?
The worry about choosing a JDK is that some new features might not be available on platforms that are at present, if I'm correct. How about making HttpClient 1.3+ compatible, then say making HttpClient 5 to run with Java 5, no new features, just a new implementation that takes advantage of Java 5's new and useful stuff..?
- Chris
From: Ortwin Gl�ck <[EMAIL PROTECTED]> Reply-To: "HttpClient Project" <[email protected]> To: HttpClient Project <[email protected]> Subject: Re: [POLL] Minimal JRE requirement for HttpClient 4.0 Date: Wed, 26 Jan 2005 10:10:39 +0100
Chris Brown wrote:Hi all,
I was thinking that one of the most annoying aspects of current releases of HttpClient (as far as I'm concerned) is that it depends upon commons-logging, and as such it's not always easy to mix-and-match with other Java APIs that use different versions of commons-logging. By settling on Java 1.4, you could use the built-in logging API (any shortcomings can be addressed by dropping in custom handlers and formatters, it's not difficult, if the user requires it).
Another possible advantage of 1.4 is that it builds in all the JSSE and JCE stuff that's useful for SSL and NTLM support.
Chris,
I want to make some statements regarding commons-logging and DLL hell.
We use commons-logging because HttpClient is a library and as such must not dictate which logging implementation to use. The user can choose the one he likes and HttpClient will use it.
Many products use common-logging. Some of them in an old version. This is a problem and usually results in a "no such method" exception. However, problems like this one are pretty normal in software development. Just look at a Linux distribution. It is essential that all binaries on a distribution use the same glibc (or any other library) version. There is no possibility that some binaries use one version and some use another version *). They all have to agree on one version to make the system work. In some cases this requires patching the original code.
The exact same thing applies to Java applications that use common libraries. All components of an applications have to agree on the same version of common libraries (or need to use ugly Classloader bricolage). As HttpClient is open source you always have the option to create a patch to an older version of the commons-logging API.
Best we can do is use the commons-logging API version that is most widely used.
Ortwin Gl�ck
*) You can argue that the dynamic linker (ld) can be controlled by some environment variable to load a specific version of a DLL. While this works for a simple dependency on a library, it doesn't in a more complex situation. In the following setup for instance the problems can not be solved by setting ld environment variables.
app ----> glibc (2.3) ----> zlib ---> glibc (2.2)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN Messenger : dialoguez en temps r�el avec vos amis ! http://g.msn.fr/FR1001/866
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
