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 00:09:53 GMT
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.
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?

>> 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.

> 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