hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Wed, 29 Jan 2014 08:57:45 GMT
On Tue, 2014-01-28 at 19:39 +0000, sebb wrote:


> >
> > Why? The new implementation honors the same contract by implementing the
> > same interfaces and using the same API classes as the old version. As
> > long as the application does not directly depend on the old
> > DefaultHttpClient (in which case we cannot do much) but rather relies on
> > HttpClient interface, the newer implementation can be used without any
> > alternations.
> Suppose the code depends on the class
> org.apache.http.entity.HttpEntityWrapper
> This won't exist in the new jar as it is one of the HC4-suffix classes.
> Assume also that the new HttpClient implementation makes use of the class
> org.apache.http.entity.HttpEntityWrapperHC4
> Seems to me that this could well cause a problem where the app works
> fine on Java but fails on Android - and the failure could be very
> tricky to debug.
> That's why I think the application needs to avoid using the classes
> that are renamed with the HC4 suffix.

It is theoretically possible but not very likely. Besides, HC4 classes
are absolutely no different from any custom interface implementation or
a custom subclass HttpClient must be able to handle. This is no
different from hitting a perfectly ordinary bug. HC4 classes are just
ugly. This is the only problem with them.

I could make some (probably most) of those classes package private, but
a few utility classes are being used all over the place and need to
remain public.


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message