On 28 January 2014 12:36, Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2014-01-28 at 11:49 +0000, sebb wrote: >> On 28 January 2014 08:28, Oleg Kalnichevski <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
