hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [Request for comments] HttpClient re-spin for Android
Date Tue, 28 Jan 2014 13:08:10 GMT
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 <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.
>
> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message