Let me make sure I understand these points (-): - HttpClient (HC) is baked in Android - This cannot be overridden by placing a new HC jar on the classpath - Android has no endorsed path mechanism like regular Java?
Hence the proposed HC4 post-fixed classes. - This is not a problem for regular Java users since one can add a new HC jar on the classpath before the old one or simply replace the old with the new. I know I've asked this before, but I'd like to repeat it in the context of this email: It seems simpler to provide a repackaged HC in org.apache.http43 or a name like it. The current cherry picking seems error prone, requires deep knowledge and would be hard to maintain. We do not like repackaging because: - It uses too many bytes? - ? Thank you, Gary On Tue, Jan 28, 2014 at 7:36 AM, 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. > > 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. > > > == > > > > 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] > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
