Android buildscript repositories: jcenter VS mavencentral

At Bintray I just rebloged a very detailed blog post describing the reasons why Google made this change. Here are the most important points:

  • JCenter is a Java repository in Bintray, which is the largest repo in the world for Java and Android OSS libraries, packages and components.
  • All the content in JCenter is served over a CDN, with a secure HTTPS connection. Back in the time of the migration (Android Studio 0.8) The central maven 2 repository was HTTP only and HTTPS wasn’t supported. Reference: 51.6.2. Maven central repository.
  • jcenter() is a superset of mavenCentral(), that encompasses many additional repositories and artifacts.
  • In different scenarios and from different countries Bintray is faster than Maven Central (e.g. from Israel). In others it is very close. Since Maven Central and Bintray use different CDNs which adaptively favor regions, this might change to both ways.
  • Bintray has a different approach to package identification than the legacy Maven Central. This is a big and serious security matter. It is important.
  • If you really need to get your package to Maven Central (for supporting legacy tools) you can do it from Bintray as well, in a click of a button or even automatically.

Regarding performance improvements, couple of android developer advocates had faced/noticed the issue of huge indexing with maven central.

In the words of Tor Norbye:

I ran AndroidStudio with a brand new settings directory, so it went and connected maven central and downloaded an index of the available artifacts.

Then I happened to look at the size of my directory.

My ~/Library/Cache/AndroidStudioPreview is 1.5G, and 1.2G of those are taken by the “Maven” subdirectory.

That’s ridiculous. We barely use the index at all. The primary use for it is the Dependency editor in the Project Structure Dialog, but we really don’t need to have a precomputed index for it. MavenCentral has a fast online JSON search we can use on demand when somebody searches for artifacts. In https://android-review.googlesource.com/#/c/94843/ we added a lint check which checks whether the dependencies are up to date, and the search for a handful of artifacts is near instant.

In short, we really don’t need the cache; it may help with code completion in .gradle and maven .pom files, but that’s not a super important usecase, and certainly not something all users should have to sacrifice 1.5G of download speed and diskspace to have the possibility of one day doing.
Read more on: The Maven index is huge!

Also, you might find this very short (1Q and 1A) discussion on Hacker News interesting.


I am with JFrog, the company behind and , see my profile for details and links.

Leave a Comment