This article had to be published much earlier (by almost six years), thereby saving Android developers a huge amount of months of meaningless development - but alas, there is not always time for this.

Introduction

If you are developing for Android, then you probably come across the fact that you open your application, which worked fine for several years, and then suddenly it turns out that Apache httpComponents have become deprecated, and they are not recommended to be used. First, let's look at what happened, and then we draw conclusions what to do.

What happened

I did not dig in too far, but many interesting things can be obtained from the org.apache.hc.dev mailing list and the Apache Jiri. For example, the fact that:
')

Android included old pre-beta release library

Moreover, throughout the history of the library version has not changed, and if you turn on apache legacy, then this is still the same pre-beta.

Confirmation can be read here .

Google just scored on the problem

Apache developers have been actively working on the library, but Google’s assigned managers did not respond for months, changed, and finally said that this was not a priority task, users have enough of the old version, and generally need to throw out this library. In confirmation - a little from the mailing list mentioned by me (the work started in 2008, and in 2010 a new manager suddenly appeared):


At the same time the first alarm bell rang:


They can not make changes to the code of an existing library due to incompatibilities? Oh rly? And if they put it in their own separate package based on the Apache code, then suddenly they can? Generally, breaking changes in Android is a separate topic that goes beyond the scope of this article, but what is worth only limiting application permissions in the six ... At the same time, the guys from Apache actively tried to provide maximum compatibility, and were ready to do anything for that. But alas.

The final

And then the library just without any adequate explanations sawed out with the official recommendation to use HttpUrlConnection. Here at least something remotely similar to the explanation of the situation from Jesse Wilson, who was at that time in the Dalvik team (by the way, he was the second Google manager for relations with Apache. Remember this name).

In his article you can see that among the benefits he sees:

• Caching (which, if necessary, is implemented anywhere)
• Low library weight (yes, but dubious argument)
• Compression, which saves the battery and speeds up the download (yes, but if you wish, we can use the Google Compression Proxy and through Apache HttpComponents as a regular proxy)

Extremely dubious explanations. If you are now sitting in a foil hat, then the rational argument is that Google thus decided to quietly force users to drive all of their traffic through their proxy ...
UPD . As I was rightly pointed out, compression means not using GCP, but using standard gzip ... Which Apache has been around for many, many years. So all the more strange.

Unfortunately, most developers blindly believe Google and immediately believe that the Apache library is “bad”, and you need to run to throw it out of your code.

Apache developers commented briefly on this:

Gossip There is nothing we can do about it.

Epilogue with OkHttp

If you are developing for Android, you probably have seen recommendations to replace Apache HttpComponents with the popular OkHttp library from Square.

Do you still remember the sweet guy Jesse Wilson from the Dalvik team? Do you know that he now works in Square ? And he is the creator of OkHttp? Moreover, you know that OkHttp started as a fork of the AOSP (Android Open Source Project), which in turn took its code from Apache Harmony?

So this is essentially the creation of a Apache fork with the subsequent ejection of the original from circulation (the second version of Jesse voiced earlier in communication with Apache). It sounds pretty mean, doesn’t it? The only thing that is not clear is whether it was an initiative of Google or Jesse himself. But he entered extremely ugly, throwing competitors with Google and came all in white with his decision.

And what?

Let's see what are the options for how to live on.

1. Use HttpUrlConnection
Google recommended approach. It really makes sense if you have a simple application. But God forbid you try to do something not quite trivial. In my practice, there were two such cases - when I tried to use SSL proxy and when I wanted to contact a certain IP address with my host name. Both tasks using HttpUrlConnection can not be implemented.

2. Use other advanced alternatives.
For example, the same OkHttp. I did not try it myself, but they say that the library is good. However, you will spend a lot of time rewriting good, ready-made code (if you already have an application). Well, regarding OkHttp - I would not use such an unpleasantly smelling fork.

3. Use the legacy library
Yes, you can continue to use all the same ancient beta as before. But why? How fast plugging a hole is a good solution, and if not ... Of course not. It's a shame that just such an answer is the most popular solution on the same stack overflow - people just don't understand that they use the 2008 version of the library.

4. Use the latest versions of Apache HttpComponents
In the pros, we have the fact that we continue to use all the same code, without wasting time rewriting and studying the new library and its bugs. Moreover, the code written in HttpComponents will work for you anywhere. The library is monstrously powerful and allows you to really do anything.
The question is how to connect it?
If you just take and substitute in the gradle, then there will be a conflict of classes with this most ancient version.
In release 4.3, apache developers suggested using special postfixes “HC4” in classes to avoid conflicts, but it worked somehow very badly.
But for release 4.5, they are already recommending another, the only logical way out - to use the library packaged under a different class space, compiled by a certain companion on the githab (link below). There, however, in fact, version 4.4, not 4.5 - but this is not so important. And if you care that you use the library compiled by anyone (although it is quite popular), then you can always compile it yourself from the sources. At the moment, I think this is the most appropriate way out of the current bad situation (and I myself am doing just that).

What's next?

So far, there are no notes on using the fifth version of the library on Android - perhaps this is because it is still in the alpha version. Or just decided to Apache no longer have to do with Google and Android. However, even if so - there will always be enthusiasts who can correctly repack the latest version. And working with her is sheer pleasure.

Links

1. Repository with repacked version of httpComponents;
2. Release Notes 4.5, which recommend using this repository;
3. Interesting fragments of correspondence guys from Apache and Google;
4. Curious problems with comments in the Apache Djire - one and two .

In the process of writing this article, I talked on this topic with an Apache developer who confirmed my assumptions, but I will not mention him out of harm's way.