Our app's build time ballooned by 2-3X or more when we went to multidex. We've had some luck reducing it, but we'd still like to axe multidex.

I definitely consider a 3X build time increase (not 30 seconds to 90 seconds, but 1 or 2 min to 5-8) to be a significant problem, bordering on nightmare... especially since we just included a few more libraries that put us past the 65k mark.

Is that what other people have seen?

It sounds like a ridiculous number of methods until you realize just importing Guava brings in 20k methods, using half the Amazon SDKs would probably bring another 20k-40k, Apache's main utils bring about 10-20k, etc.

I mean, it means you can't pull in Scala. I mean, you can, but pull in enough bloated Java 3rd party libraries and you might be hitting that limit pretty quickly. Google broke Google Play Services out into a large number of small dependencies once they were past the 15k method mark. Mind you, certain compilation settings will totally strip out unused methods, but it's still annoying.

For example, the amazon sdk jar has 40,000 alone or something insane. You can hit if you're using a few large libraries.

That said, you can use proguard to strip your unused methods and it usually fine even for large applications.

Java's crippled generics, lack of tuple support, and lack of default parameters encourage interface bloat in utility libraries.

Given how bloody good Java IDEs are (By which I mean to say - how good IntelliJ is), the cognitive cost of this interface bloat is very low... Until you start developing for Android.

IIRC the Facebook app had many more than that at one point, and had to use multi-dexing. Not sure if that's still the case.

I've also heard that scala apps on Android can sometimes hit the limit, because pulling in the scala stdlib greatly bloats the method count.

Because of "single responsibility principle" it's better if classes and methods do one thing. That usually leads to lots of small classes and small methods.

Ad SDK's have tons of methods.