HttpClient in Android

[olegk]

Hi Jesse

As far as I know Android still ships with a very old, pre-BETA version
of HttpClient 4.0. There have been numerous changes in the HttpClient
main code line, which, sadly, have not been picked up by Android. My
main concern is that the more two code lines stay out of sync, the more
they deviate from one another the more difficult it may become for you
to rebase your code line to the latest snapshot upstream.

We have also been deprecating code in HttpClient. At some point of time
I would like to start removing old code that has been deprecated for a
couple of GA releases. Since you have been skipping releases it will be
impossible to remove deprecated code without breaking API compatibility
with the version of HttpClient shipped with Android.

Could you please share with us your plans regarding HttpClient and let
us know whether you intend to upgrade to the latest 4.0.x release at
some point?

Cheers

Oleg  


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jesse Wilson-4]

Oleg,

I'm quite sorry that Android included an unreleased rev of Apache HTTP
client, and I suspect we'll be paying for that mistake for quite a while.

Because of the strict compatibility requirements of our platform, we will be
unable to make forwards-incompatible API changes to the HTTP code. Unlike
your desktop and serverside users, including the API as a part of the core
platform significantly reduces our ability to make API changes.

These days we aren't spending much time on the HTTP client code. Our users
seem to be mostly satisfied with the ancient version in the SDK, and have
been directing their complaints elsewhere (crypto, locales, XML...).

That said, we do want to figure out a long term strategy for an HTTP client
API that will work for both us and the Apache HTTP client team. We're
considering a variety of options...

   - Discouraging our users from using the built-in Apache HTTP client,
   preferring the JDK's own URLConnection classes. Whether this is feasible
   depends mostly on whether the new APIs in Java 6 (which we're working on)
   will satisfy the use cases that Apache HTTP client has covered for years.

   - Replacing the Apache HTTP client API with a 3rd API in a "com.google"
   or "android." package. Such an API would likely be based on parts of your
   own code, but with a more limited API.

   - Tidying up the version of Apache HTTP that we're already stuck with.
   This includes deprecating APIs that shouldn't have ever been exposed as
   public, and possibly filling in any gaps using newer code from your project.

But none of this work is particularly urgent since we're actively fighting
fires in other areas of the core libraries.

Cheers,
Jesse


On Tue, Mar 16, 2010 at 2:45 AM, Oleg Kalnichevski <olegk@...> wrote:

> Hi Jesse
>
> As far as I know Android still ships with a very old, pre-BETA version
> of HttpClient 4.0. There have been numerous changes in the HttpClient
> main code line, which, sadly, have not been picked up by Android. My
> main concern is that the more two code lines stay out of sync, the more
> they deviate from one another the more difficult it may become for you
> to rebase your code line to the latest snapshot upstream.
>
> We have also been deprecating code in HttpClient. At some point of time
> I would like to start removing old code that has been deprecated for a
> couple of GA releases. Since you have been skipping releases it will be
> impossible to remove deprecated code without breaking API compatibility
> with the version of HttpClient shipped with Android.
>
> Could you please share with us your plans regarding HttpClient and let
> us know whether you intend to upgrade to the latest 4.0.x release at
> some point?
>
> Cheers
>
> Oleg
>
>

[olegk]

Jesse Wilson wrote:

> Oleg,
>
> I'm quite sorry that Android included an unreleased rev of Apache HTTP
> client, and I suspect we'll be paying for that mistake for quite a while.
>
> Because of the strict compatibility requirements of our platform, we will be
> unable to make forwards-incompatible API changes to the HTTP code. Unlike
> your desktop and serverside users, including the API as a part of the core
> platform significantly reduces our ability to make API changes.
>
> These days we aren't spending much time on the HTTP client code. Our users
> seem to be mostly satisfied with the ancient version in the SDK, and have
> been directing their complaints elsewhere (crypto, locales, XML...).
>
> That said, we do want to figure out a long term strategy for an HTTP client
> API that will work for both us and the Apache HTTP client team. We're
> considering a variety of options...
>
>    - Discouraging our users from using the built-in Apache HTTP client,
>    preferring the JDK's own URLConnection classes. Whether this is feasible
>    depends mostly on whether the new APIs in Java 6 (which we're working on)
>    will satisfy the use cases that Apache HTTP client has covered for years.
>
>    - Replacing the Apache HTTP client API with a 3rd API in a "com.google"
>    or "android." package. Such an API would likely be based on parts of your
>    own code, but with a more limited API.
>
>    - Tidying up the version of Apache HTTP that we're already stuck with.
>    This includes deprecating APIs that shouldn't have ever been exposed as
>    public, and possibly filling in any gaps using newer code from your project.
>
> But none of this work is particularly urgent since we're actively fighting
> fires in other areas of the core libraries.
>
> Cheers,
> Jesse
>
>  

Jesse,

The current snapshot of HttpClient 4.x still maintains API compatibility
with the version shipping with Android.

It would be truly, truly sad if Google chose to deprecate HttpClient or
replace it with some other API. Whatever reason and intent this decision
could be based upon, that would be quite a setback for us as a project.

We had to rush the 4.0 API freeze per agreement with Bob Lee to be in
time for the first official Android release. So, we were stuck with that
API baseline ever since, even though I often wished we still had freedom
to make some tweaks to it. Nonetheless, we kept out side of the deal.
The initial plan and the expectation on our part was that Google would
sync up with our code line once HttpClient 4.0 was officially released.
Sadly, that did not happen.

I understand that in the grand scheme of things we are very small. Now
that Android is a major success we are no longer needed.

Oleg




 

> On Tue, Mar 16, 2010 at 2:45 AM, Oleg Kalnichevski <olegk@...> wrote:
>
>  
>> Hi Jesse
>>
>> As far as I know Android still ships with a very old, pre-BETA version
>> of HttpClient 4.0. There have been numerous changes in the HttpClient
>> main code line, which, sadly, have not been picked up by Android. My
>> main concern is that the more two code lines stay out of sync, the more
>> they deviate from one another the more difficult it may become for you
>> to rebase your code line to the latest snapshot upstream.
>>
>> We have also been deprecating code in HttpClient. At some point of time
>> I would like to start removing old code that has been deprecated for a
>> couple of GA releases. Since you have been skipping releases it will be
>> impossible to remove deprecated code without breaking API compatibility
>> with the version of HttpClient shipped with Android.
>>
>> Could you please share with us your plans regarding HttpClient and let
>> us know whether you intend to upgrade to the latest 4.0.x release at
>> some point?
>>
>> Cheers
>>
>> Oleg
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bob Lee-5]

While I don't work for Google anymore, Android is an open source project, so
I like to think I can still make contributions (at least after I launch my
current product :-)).

On Thu, Mar 18, 2010 at 2:55 PM, Oleg Kalnichevski <olegk@...> wrote:

> The current snapshot of HttpClient 4.x still maintains API compatibility
> with the version shipping with Android.
>

Last I checked, the mainline HttpClient made incompatible changes after
Android shipped (protected member modifications count). This is why Android
hasn't just dropped in an upgrade. Android could certainly benefit from bug
fixes; I don't think stale connection checking works, for example.


> I understand that in the grand scheme of things we are very small. Now that
> Android is a major success we are no longer needed.


The HttpClient library is heavily used in Android apps, so it's very much
needed. I use it in my app. Any bug fixes and performance improvements could
have a big impact on overall performance, battery life and stability.

I can think of a few options going forward:

  1. Redo the incompatible changes in a way that's compatible with both
Android's version and the mainline HttpClient. This may or may not be
possible. I haven't dug too deeply.

  2. Maybe the changes are in an obscure part of the API that we're certain
no one uses. We'd deliberately introduce a compatibility bug to fix a # of
bugs that actually affect users. I recall that one of the incompatible
changes fixed stale connection checking.

  3. Make the HttpClient library optional. Include it for older Android apps
by default. Newer apps will need to import it using use-library. Newer apps
will be able to bundle their own updated version of HttpClient (or some
other lib). We should probably do this either way.

Bob

[olegk]

Bob Lee wrote:

> While I don't work for Google anymore, Android is an open source project, so
> I like to think I can still make contributions (at least after I launch my
> current product :-)).
>
> On Thu, Mar 18, 2010 at 2:55 PM, Oleg Kalnichevski <olegk@...> wrote:
>
>> The current snapshot of HttpClient 4.x still maintains API compatibility
>> with the version shipping with Android.
>>
>
> Last I checked, the mainline HttpClient made incompatible changes after
> Android shipped (protected member modifications count). This is why Android
> hasn't just dropped in an upgrade. Android could certainly benefit from bug
> fixes; I don't think stale connection checking works, for example.
>
>

Bob,

Every time a new release of HttpClient is cut it is checked for binary
compatibility with the previous version using clirr. Maybe Google has a
better tool, but clirr served us quite well in the past.

The strict interpretation of full binary compatibility with the version
tagged as 4_0_API_FREEZE was compromised by making several protected
variables final (listed in the 4.0 release notes). Those variables are
used in impl classes and should have never been a part of the public API
to start with. I was simply in a hurry and could not review every single
area of the library before the API freeze.

I wrote to you _twice_ shortly before the final release to ask about
your opinion whether this could be acceptable for Google or you would
rather prefer to have those changes reverted. Since I got no response I
had no other option but to assume that was not important. You went
silent and no one else from Google approached us.

Even at this point it would still be very easy to make those variables
non-final, if this is the only sticking point.

Again, I believe we stuck to our part of the deal.

Oleg

>> I understand that in the grand scheme of things we are very small. Now that
>> Android is a major success we are no longer needed.
>
>
> The HttpClient library is heavily used in Android apps, so it's very much
> needed. I use it in my app. Any bug fixes and performance improvements could
> have a big impact on overall performance, battery life and stability.
>
> I can think of a few options going forward:
>
>   1. Redo the incompatible changes in a way that's compatible with both
> Android's version and the mainline HttpClient. This may or may not be
> possible. I haven't dug too deeply.
>
>   2. Maybe the changes are in an obscure part of the API that we're certain
> no one uses. We'd deliberately introduce a compatibility bug to fix a # of
> bugs that actually affect users. I recall that one of the incompatible
> changes fixed stale connection checking.
>
>   3. Make the HttpClient library optional. Include it for older Android apps
> by default. Newer apps will need to import it using use-library. Newer apps
> will be able to bundle their own updated version of HttpClient (or some
> other lib). We should probably do this either way.
>
> Bob
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bob Lee-5]

On Thu, Mar 18, 2010 at 5:55 PM, Oleg Kalnichevski <olegk@...> wrote:

> I wrote to you _twice_ shortly before the final release to ask about your
> opinion whether this could be acceptable for Google or you would rather
> prefer to have those changes reverted. Since I got no response I had no
> other option but to assume that was not important. You went silent and no
> one else from Google approached us.
>

Ohhhhh... I thought you were talking about the incompatibilities introduced
in beta3, which I think you already fixed. I didn't realize there were more
in an even later release. Here's the list you sent me:

[ERROR] org.apache.http.conn.BasicEofSensorWatcher: Field attemptReuse is
now final
[ERROR] org.apache.http.conn.BasicEofSensorWatcher: Field managedConn is now
final
[ERROR] org.apache.http.impl.client.RoutedRequest: Accessibility of field
request has been weakened from protected to private
[ERROR] org.apache.http.impl.client.RoutedRequest: Accessibility of field
route has been weakened from protected to private
[ERROR] org.apache.http.impl.conn.DefaultClientConnectionOperator: Field
schemeRegistry is now final
[ERROR] org.apache.http.impl.conn.DefaultHttpRoutePlanner: Field
schemeRegistry is now final
[ERROR] org.apache.http.impl.conn.ProxySelectorRoutePlanner: Field
schemeRegistry is now final
[ERROR] org.apache.http.impl.conn.SingleClientConnManager: Field
alwaysShutDown is now final
[ERROR] org.apache.http.impl.conn.SingleClientConnManager: Field
connOperator is now final
[ERROR] org.apache.http.impl.conn.SingleClientConnManager: Field
schemeRegistry is now final
[ERROR] org.apache.http.impl.conn.tsccm.ConnPoolByRoute: Removed field
maxTotalConnections
[ERROR] org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: Field
connOperator is now final
[ERROR] org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: Field
schemeRegistry is now final
[ERROR] org.apache.http.impl.cookie.BrowserCompatSpec: Accessibility of
field DATE_PATTERNS has been weakened from protected to private


Are these the only incompatibilities with Android? Reverting those changes
would certainly help the Android team get the change through. If that
happens, it should be relatively easy to drop in a new version. I think I
did away with most if not all of the Android-specific changes a long time
ago.

I'd love to see the stale connection checking bug fixed. Oleg, are there
other high profile bugs that you know of?

Thanks,
Bob

[olegk]

On Thu, 2010-03-18 at 18:47 -0500, Bob Lee wrote:

> On Thu, Mar 18, 2010 at 5:55 PM, Oleg Kalnichevski <olegk@...> wrote:
>
> > I wrote to you _twice_ shortly before the final release to ask about your
> > opinion whether this could be acceptable for Google or you would rather
> > prefer to have those changes reverted. Since I got no response I had no
> > other option but to assume that was not important. You went silent and no
> > one else from Google approached us.
> >
>
> Ohhhhh... I thought you were talking about the incompatibilities introduced
> in beta3, which I think you already fixed. I didn't realize there were more
> in an even later release. Here's the list you sent me:
>

Oh, come on.

> [ERROR] org.apache.http.conn.BasicEofSensorWatcher: Field attemptReuse is
> now final
> [ERROR] org.apache.http.conn.BasicEofSensorWatcher: Field managedConn is now
> final
> [ERROR] org.apache.http.impl.client.RoutedRequest: Accessibility of field
> request has been weakened from protected to private
> [ERROR] org.apache.http.impl.client.RoutedRequest: Accessibility of field
> route has been weakened from protected to private
> [ERROR] org.apache.http.impl.conn.DefaultClientConnectionOperator: Field
> schemeRegistry is now final
> [ERROR] org.apache.http.impl.conn.DefaultHttpRoutePlanner: Field
> schemeRegistry is now final
> [ERROR] org.apache.http.impl.conn.ProxySelectorRoutePlanner: Field
> schemeRegistry is now final
> [ERROR] org.apache.http.impl.conn.SingleClientConnManager: Field
> alwaysShutDown is now final
> [ERROR] org.apache.http.impl.conn.SingleClientConnManager: Field
> connOperator is now final
> [ERROR] org.apache.http.impl.conn.SingleClientConnManager: Field
> schemeRegistry is now final
> [ERROR] org.apache.http.impl.conn.tsccm.ConnPoolByRoute: Removed field
> maxTotalConnections
> [ERROR] org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: Field
> connOperator is now final
> [ERROR] org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager: Field
> schemeRegistry is now final
> [ERROR] org.apache.http.impl.cookie.BrowserCompatSpec: Accessibility of
> field DATE_PATTERNS has been weakened from protected to private
>
>
> Are these the only incompatibilities with Android?

The correct list of incompatibilities can be found in the official
release notes:

http://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES.txt

Eleven protected variables in some obscure areas of connection
management code were made final to help ensure their thread safety.


> Reverting those changes
> would certainly help the Android team get the change through. If that
> happens, it should be relatively easy to drop in a new version. I think I
> did away with most if not all of the Android-specific changes a long time
> ago.
>

Those changes were made for a reason. Their consequences were discussed
on the mailing list. You were consulted twice and asked to raise your
objection.

http://markmail.org/message/nt5xsdstisygam3a

Giving this as a reason for not following through with the initial plan
does not seem fair.

I can revert the changes, no problem. However, the Android team should
make up their mind about the future plans first. I would be silly to
revert the changes just to find out later Google has some other reasons
for not upgrading.

If Jesse confirms those final variables is the only sticking point, I'll
make them non-final and cut a new official release.


> I'd love to see the stale connection checking bug fixed. Oleg, are there
> other high profile bugs that you know of?
>

I can't think of anything severe other than race conditions in the
connection management code found in BETA versions, which have been fixed
in the final release. There has also been an important performance fix
related to excessive Log lookups in short lived objects.

There have been a number of non-severe bug fixes which Android should
pick up nonetheless.

Cheers

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bob Lee-5]

On Fri, Mar 19, 2010 at 4:56 AM, Oleg Kalnichevski <olegk@...> wrote:

> Oh, come on.
>

Um, OK. I was just trying to be helpful but should be focusing on other
things right now. Jesse already explained that the Android team is swamped,
and they haven't had any complaints about HttpClient, so upgrading it has
been a relatively low priority. Android is open source. If someone feels
strongly about updating HttpClient sooner rather later, they can submit a
patch <http://source.android.com/download>.

I'm sorry I didn't have time to process your original email. There are only
so many hours in a day. I explained on several earlier occasions that
Android doesn't allow binary incompatibilities of any kind (not my rule). I
understand that the HttpClient team is more tolerant of binary
incompatibilities. While I'm not saying it would be impossible to make these
changes in Android, I am saying that it would take a lot of convincing (and
time), it would annoy other people who are time-constrained and who have
higher priorities, and it could likely fail anyway.

Bob

[juliusdavies]

I'm developing a tool to try and match random jar files against known jar files.

I ran the tool against the Android-7 jar file
(android-sdk-linux_86/platforms/android-7/android.jar), and here's
what my tool returned:



Best match:  'httpcore-4.0-beta2.jar' with 92 matching signatures.

Best match:  'httpclient-4.0-beta1.jar' with 127 matching signatures.


This doesn't guarantee that those are indeed the exact versions in
Android, but I have some confidence, since versions immediately before
and after happened to also be in my database.


Raw results:

 jakarta-httpcore-4.0-alpha1.jar | 2006-04-16 04:01:08 |  21
 jakarta-httpcore-4.0-alpha2.jar | 2006-06-08 16:59:10 |  23
 jakarta-httpcore-4.0-alpha3.jar | 2006-12-07 07:50:16 |  26
 jakarta-httpcore-4.0-alpha4.jar | 2007-03-23 23:50:30 |  31
 httpcore-4.0-alpha5.jar         | 2007-06-28 23:53:46 |  35
 httpcore-4.0-alpha6.jar         | 2007-10-05 19:01:12 |  65
 httpcore-4.0-beta1.jar          | 2008-01-21 02:10:46 |  88
 httpcore-4.0-beta2.jar          | 2008-06-18 02:35:46 |  92
 httpcore-4.0-beta3.jar          | 2008-10-15 03:37:48 |  88
 httpcore-4.0.jar                | 2009-02-20 04:00:22 |  87
 httpcore-4.0.1.jar              | 2009-06-19 03:06:14 |  87
 httpcore-4.1-alpha1.jar         | 2009-09-06 19:37:24 |  84


 httpclient-4.0-alpha1.jar       | 2007-07-15 00:43:50 |  31
 httpclient-4.0-alpha2.jar       | 2007-11-06 23:00:30 |  53
 httpclient-4.0-alpha3.jar       | 2008-02-21 04:46:38 |  67
 httpclient-4.0-alpha4.jar       | 2008-05-05 00:37:32 |  83
 httpclient-4.0-beta1.jar        | 2008-08-23 18:48:30 | 127
 httpclient-4.0-beta2.jar        | 2008-12-18 04:13:42 | 125
 httpclient-4.0.jar              | 2009-08-07 03:40:44 | 119
 httpclient-4.0.1.jar            | 2009-12-10 04:06:18 | 117
 httpclient-4.1-alpha1.jar       | 2009-12-10 04:25:42 | 110


I hope this information can be of some help.


yours,

Julius

>
> Um, OK. I was just trying to be helpful but should be focusing on other
> things right now. Jesse already explained that the Android team is swamped,
> and they haven't had any complaints about HttpClient, so upgrading it has
> been a relatively low priority. Android is open source. If someone feels
> strongly about updating HttpClient sooner rather later, they can submit a
> patch <http://source.android.com/download>.
>
> I'm sorry I didn't have time to process your original email. There are only
> so many hours in a day. I explained on several earlier occasions that
> Android doesn't allow binary incompatibilities of any kind (not my rule). I
> understand that the HttpClient team is more tolerant of binary
> incompatibilities. While I'm not saying it would be impossible to make these
> changes in Android, I am saying that it would take a lot of convincing (and
> time), it would annoy other people who are time-constrained and who have
> higher priorities, and it could likely fail anyway.
>
> Bob
>

--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[juliusdavies]

ps.  The signature count means # of classes with exactly the same
signature, and in this case signature means all 5 of these attributes
matched:

1. fully qualified class name
2. class modifiers and visibility, as well as extends, implements
3. all method names, parameter types, return types, and throws types
4. all method modifiers and visibility (e.g. static, final, protected,
private, synchronized)
5. all methods must appear in the same order in the class

Private methods are also included in the matching, so the fact that
fewer signatures match in httpcore-4.0 could be from private methods
changing.





On Fri, Apr 23, 2010 at 1:08 PM, Julius Davies <juliusdavies@...> wrote:

> I'm developing a tool to try and match random jar files against known jar files.
>
> I ran the tool against the Android-7 jar file
> (android-sdk-linux_86/platforms/android-7/android.jar), and here's
> what my tool returned:
>
>
>
> Best match:  'httpcore-4.0-beta2.jar' with 92 matching signatures.
>
> Best match:  'httpclient-4.0-beta1.jar' with 127 matching signatures.
>
>
> This doesn't guarantee that those are indeed the exact versions in
> Android, but I have some confidence, since versions immediately before
> and after happened to also be in my database.
>
>
> Raw results:
>
>  jakarta-httpcore-4.0-alpha1.jar | 2006-04-16 04:01:08 |  21
>  jakarta-httpcore-4.0-alpha2.jar | 2006-06-08 16:59:10 |  23
>  jakarta-httpcore-4.0-alpha3.jar | 2006-12-07 07:50:16 |  26
>  jakarta-httpcore-4.0-alpha4.jar | 2007-03-23 23:50:30 |  31
>  httpcore-4.0-alpha5.jar         | 2007-06-28 23:53:46 |  35
>  httpcore-4.0-alpha6.jar         | 2007-10-05 19:01:12 |  65
>  httpcore-4.0-beta1.jar          | 2008-01-21 02:10:46 |  88
>  httpcore-4.0-beta2.jar          | 2008-06-18 02:35:46 |  92
>  httpcore-4.0-beta3.jar          | 2008-10-15 03:37:48 |  88
>  httpcore-4.0.jar                | 2009-02-20 04:00:22 |  87
>  httpcore-4.0.1.jar              | 2009-06-19 03:06:14 |  87
>  httpcore-4.1-alpha1.jar         | 2009-09-06 19:37:24 |  84
>
>
>  httpclient-4.0-alpha1.jar       | 2007-07-15 00:43:50 |  31
>  httpclient-4.0-alpha2.jar       | 2007-11-06 23:00:30 |  53
>  httpclient-4.0-alpha3.jar       | 2008-02-21 04:46:38 |  67
>  httpclient-4.0-alpha4.jar       | 2008-05-05 00:37:32 |  83
>  httpclient-4.0-beta1.jar        | 2008-08-23 18:48:30 | 127
>  httpclient-4.0-beta2.jar        | 2008-12-18 04:13:42 | 125
>  httpclient-4.0.jar              | 2009-08-07 03:40:44 | 119
>  httpclient-4.0.1.jar            | 2009-12-10 04:06:18 | 117
>  httpclient-4.1-alpha1.jar       | 2009-12-10 04:25:42 | 110
>
>
> I hope this information can be of some help.
>
>
> yours,
>
> Julius
>
>
>
>>
>> Um, OK. I was just trying to be helpful but should be focusing on other
>> things right now. Jesse already explained that the Android team is swamped,
>> and they haven't had any complaints about HttpClient, so upgrading it has
>> been a relatively low priority. Android is open source. If someone feels
>> strongly about updating HttpClient sooner rather later, they can submit a
>> patch <http://source.android.com/download>.
>>
>> I'm sorry I didn't have time to process your original email. There are only
>> so many hours in a day. I explained on several earlier occasions that
>> Android doesn't allow binary incompatibilities of any kind (not my rule). I
>> understand that the HttpClient team is more tolerant of binary
>> incompatibilities. While I'm not saying it would be impossible to make these
>> changes in Android, I am saying that it would take a lot of convincing (and
>> time), it would annoy other people who are time-constrained and who have
>> higher priorities, and it could likely fail anyway.
>>
>> Bob
>>
>
>
>
> --
> yours,
>
> Julius Davies
> 250-592-2284 (Home)
> 250-893-4579 (Mobile)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>

--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Fri, 2010-04-23 at 13:08 -0700, Julius Davies wrote:

> I'm developing a tool to try and match random jar files against known jar files.
>
> I ran the tool against the Android-7 jar file
> (android-sdk-linux_86/platforms/android-7/android.jar), and here's
> what my tool returned:
>
>
>
> Best match:  'httpcore-4.0-beta2.jar' with 92 matching signatures.
>
> Best match:  'httpclient-4.0-beta1.jar' with 127 matching signatures.
>

It think this is pretty accurate. I have always thought Android shipped
with HttpCore 4.0b2 and a snapshot of HttpClient taken a few days before
4.0b1

http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4_0_API_FREEZE/

You might want to build the snapshot and see if it produces a better
match.

Cheers

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[juliusdavies]

Thanks, Oleg!

At the moment the 4_0_API_FREEZE build matches 127 signatures, so a
tie with beta1.

But I'm looking closely at the diff, and I see one change that should
increase the match count:


  336 +++ module-client/src/main/java/org/apache/http/conn/ssl/SSLSocketFactory.java
 (.../4.0-beta1) (revision 937733)
    337 @@ -216,6 +216,20 @@
    338          this(TLS, null, null, truststore, null, null);
    339      }
    340
    341 +    public SSLSocketFactory(
    342 +        final SSLContext sslContext,
    343 +        final HostNameResolver nameResolver)
    344 +    {
    345 +        this.sslcontext = sslContext;
    346 +        this.socketfactory = this.sslcontext.getSocketFactory();
    347 +        this.nameResolver = nameResolver;
    348 +    }
    349 +
    350 +    public SSLSocketFactory(final SSLContext sslContext)
    351 +    {
    352 +        this(sslContext, null);
    353 +    }
    354 +


So I'm trying to dig deeper into that to see why my tool is messing up.


My tool also missed this, but it can't handle inner classes yet:

    201 +++ module-client/src/main/java/org/apache/http/impl/client/DefaultHttpClient.java

    231 +    // FIXME: remove this class when protocol interceptors in HttpCore
    232 +    // are updated to ignore CONNECT methods
    233 +    static class IgnoreConnectMethod implements
HttpRequestInterceptor {
    234 +



yours,

Julius


On Sat, Apr 24, 2010 at 1:46 AM, Oleg Kalnichevski <olegk@...> wrote:

> On Fri, 2010-04-23 at 13:08 -0700, Julius Davies wrote:
>> I'm developing a tool to try and match random jar files against known jar files.
>>
>> I ran the tool against the Android-7 jar file
>> (android-sdk-linux_86/platforms/android-7/android.jar), and here's
>> what my tool returned:
>>
>>
>>
>> Best match:  'httpcore-4.0-beta2.jar' with 92 matching signatures.
>>
>> Best match:  'httpclient-4.0-beta1.jar' with 127 matching signatures.
>>
>
> It think this is pretty accurate. I have always thought Android shipped
> with HttpCore 4.0b2 and a snapshot of HttpClient taken a few days before
> 4.0b1
>
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4_0_API_FREEZE/
>
> You might want to build the snapshot and see if it produces a better
> match.
>
> Cheers
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[juliusdavies]

Interesting... Android's SSLSocketFactory.java doesn't have

     private static KeyManager[] createKeyManagers(KeyStore,String)


In addition, it appears that in Android's version every method just does this:

 throw new RuntimeException("Stub!");


Okay, whew, my tool seems okay.


public class T {
    public static void main(String[] args) {
        org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory();
    }
}


$ java -cp lib/android.jar:build/jarchive.jar
ca.juliusdavies.csc589d.jarchive.T
Exception in thread "main" java.lang.RuntimeException: Stub!
        at org.apache.http.conn.ssl.SSLSocketFactory.getSocketFactory(SSLSocketFactory.java:9)
        at ca.juliusdavies.csc589d.jarchive.T.main(T.java:12)





yours,

Julius



On Sat, Apr 24, 2010 at 6:46 PM, Julius Davies <juliusdavies@...> wrote:

> Thanks, Oleg!
>
> At the moment the 4_0_API_FREEZE build matches 127 signatures, so a
> tie with beta1.
>
> But I'm looking closely at the diff, and I see one change that should
> increase the match count:
>
>
>  336 +++ module-client/src/main/java/org/apache/http/conn/ssl/SSLSocketFactory.java
>  (.../4.0-beta1) (revision 937733)
>    337 @@ -216,6 +216,20 @@
>    338          this(TLS, null, null, truststore, null, null);
>    339      }
>    340
>    341 +    public SSLSocketFactory(
>    342 +        final SSLContext sslContext,
>    343 +        final HostNameResolver nameResolver)
>    344 +    {
>    345 +        this.sslcontext = sslContext;
>    346 +        this.socketfactory = this.sslcontext.getSocketFactory();
>    347 +        this.nameResolver = nameResolver;
>    348 +    }
>    349 +
>    350 +    public SSLSocketFactory(final SSLContext sslContext)
>    351 +    {
>    352 +        this(sslContext, null);
>    353 +    }
>    354 +
>
>
> So I'm trying to dig deeper into that to see why my tool is messing up.
>
>
> My tool also missed this, but it can't handle inner classes yet:
>
>    201 +++ module-client/src/main/java/org/apache/http/impl/client/DefaultHttpClient.java
>
>    231 +    // FIXME: remove this class when protocol interceptors in HttpCore
>    232 +    // are updated to ignore CONNECT methods
>    233 +    static class IgnoreConnectMethod implements
> HttpRequestInterceptor {
>    234 +
>
>
>
> yours,
>
> Julius
>
>
> On Sat, Apr 24, 2010 at 1:46 AM, Oleg Kalnichevski <olegk@...> wrote:
>> On Fri, 2010-04-23 at 13:08 -0700, Julius Davies wrote:
>>> I'm developing a tool to try and match random jar files against known jar files.
>>>
>>> I ran the tool against the Android-7 jar file
>>> (android-sdk-linux_86/platforms/android-7/android.jar), and here's
>>> what my tool returned:
>>>
>>>
>>>
>>> Best match:  'httpcore-4.0-beta2.jar' with 92 matching signatures.
>>>
>>> Best match:  'httpclient-4.0-beta1.jar' with 127 matching signatures.
>>>
>>
>> It think this is pretty accurate. I have always thought Android shipped
>> with HttpCore 4.0b2 and a snapshot of HttpClient taken a few days before
>> 4.0b1
>>
>> http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4_0_API_FREEZE/
>>
>> You might want to build the snapshot and see if it produces a better
>> match.
>>
>> Cheers
>>
>> Oleg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
>
> --
> yours,
>
> Julius Davies
> 250-592-2284 (Home)
> 250-893-4579 (Mobile)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>

--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...