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 11:49:07 GMT
On 28 January 2014 08:28, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Tue, 2014-01-28 at 00:09 +0000, sebb wrote:
>> On 27 January 2014 20:39, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Mon, 2014-01-27 at 20:14 +0000, sebb wrote:
>> >> On 27 January 2014 19:43, Oleg Kalnichevski <olegk@apache.org> wrote:
>> >> > On Mon, 2014-01-27 at 19:33 +0000, sebb wrote:
>> >> >> On 27 January 2014 18:54, Oleg Kalnichevski <olegk@apache.org>
wrote:
>> >> >> > On Mon, 2014-01-27 at 13:24 -0500, Gary Gregory wrote:
>> >> >> >> Wow this is confusing! Why not repackage the classes instead
of renaming each one with an HC4 postfix?
>> >> >> >>
>> >> >> >
>> >> >> > That was my initial plan, too. But try re-writing the sources
using
>> >> >> > regex when you have multiple classes with the same name. I
had to give
>> >> >> > up after a full day of wasted efforts. My regex skills are
very basic,
>> >> >> > though. So, improvements are highly welcome
>> >> >> >
>> >> >> > http://svn.apache.org/repos/asf/httpcomponents/httpclient-android/trunk/build.gradle
>> >> >>
>> >> >> How do you decide which classes need renaming, and which ones don't?
>> >> >>
>> >> >
>> >> > By comparing different versions using reflection. It is in the script.
>> >>
>> >> The script contains lots of special ("magic") package and class names,
>> >> so presumably a simple comparison is not sufficient.
>> >> How are these exceptions determined?
>> >>
>> >
>> > There are several differences between version 4.0-beta1 used by the
>> > script and some arbitrary snapshot taken by Google. Some things
>> > unfortunately have to be adjusted manually.
>>
>> If they took a snapshot, there must be a corresponding revision.
>
> How do you suggest to find it out?

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.

>> It would be trivial to create a tag once the revision has been established.
>>
>> >> >> ==
>> >> >>
>> >> >> Are there likely to be many developers who need to provide an
>> >> >> application that runs unmodified on both Android and Java?
>> >> >> If not, then it would surely be sufficient to just provide a shaded
>> >> >> version for Android which uses a different package name?
>> >> >>
>> >> >
>> >> > Maybe not. But there are enough applications that are compiled against
>> >> > Android APIs that cannot be used with repackaged code.
>> >>
>> >> Not sure I follow.
>> >>
>> >> If an app is compiled against the Android APIs, I don't see how it can
>> >> take advantage of any new classes without changing the source and
>> >> recompiling.
>> >
>> > How about multiple implementations of the same abstract API, one being
>> > newer and containing fewer bugs?
>>
>> If the implementation class name is the same, I don't see how the two
>> versions can co-exist without classpath issues.
>> If the implementation is a new class, I'm not sure how the existing
>> binary code can take advantage of the new implementation.
>> What would cause the existing code to find the newer class?
>>
>
> Sigh. How about applications (or libraries) that rely on interfaces
> instead of concrete implementation classes?

An existing application needs to create the concrete class somehow, so
there must be something in the code that creates it using the existing
implementation.

Suppose you add a jar with a new implementation - how does the code
now know to start using the new implementation instead?
The original implementation will still be on the classpath - what
stops it being used?

I don't see how the situation can change without modifying the
original application in some way (for example providing a new
HttpClient class as shown below).

AIUI one goal was to allow existing apps to take advantage of the new
code without requiring a rebuild.
I don't see how that can be achieved.

>> >> In which case, would it not make sense to convert the code to use all
>> >> new class names?
>> >>
>> >> Maybe I'm missing something, but I'm not seeing any great advantage to
>> >> the proposed Android build.
>> >>
>> >
>> > 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.

However, this will only work reliably if the application avoids using
any implementation classes that have been replaced in the new library.

==

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.

> 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