hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 28 Jan 2014 19:39:21 GMT
On 28 January 2014 12:36, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Tue, 2014-01-28 at 11:49 +0000, sebb wrote:
>> On 28 January 2014 08:28, Oleg Kalnichevski <olegk@apache.org> wrote:
>
> ...
>
>> One way is trial and error by source comparison.
>> It would be tedious. If Google took a formal release (rather than a
>> snapshot) then the process would be a lot quicker of course.
>>
>
> Tedious and almost useless given the net gain.
>
> ...
>
>> >> > If you are familiar with Spring, think of Spring Rest template.
>> >>
>> >> No, I'm afraid I have no experience of Spring.
>> >>
>> >
>> > I hope this will help you understand what I am trying to achieve and why
>> > it is important:
>> >
>> > http://docs.spring.io/spring-android/docs/1.0.1.RELEASE/api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#setHttpClient%28org.apache.http.client.HttpClient%29
>>
>> I see.
>>
>
> Ah.
>
>> However, this will only work reliably if the application avoids using
>> any implementation classes that have been replaced in the new library.
>>
>
> 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.

> The whole is not to provide a drop-in replacement but a backward
> compatible alternative with fewer bugs and more features, which can be
> used with all those 3rd party libraries such as Spring for Android.

That is now clear to me.

>> ==
>>
>> The README talks about ensuring compatibility between Android and Java
>> applications by avoiding certain classes.
>> Maybe the original classes need to be tagged in some way in the Java
>> source so that people developing Java applications have advance
>> knowledge of which classes won't be available on Android. If the
>> tagging were done consistently, it could then potentially be used to
>> drive the "shading" process, avoiding the need to include magic
>> strings in the gradle script.
>>
>
> I really would not like to pollute the stock version of HttpClient with
> Android specific stuff, hence my intention to keep most of the migration
> logic in the script even at the price of having to employ some dark
> magic.
>
> This port is a stopgap solution until the next major release (which is
> still in some distant and uncertain future). It should eventually
> disappear.
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Mime
View raw message