Hello World, meet our new experimental toolchain, Jack and Jill | Hacker News Reader

Hello World, meet our new experimental toolchain, Jack and Jill

android-developers.blogspot.com

53 pointsgeekrax15 comments

This and multidex should make Android developers' lives a lot easier. I just hope Google fully supports these tools and irons out any issues that come up.

What exactly is going to be easier?

Multidexing allows developers to bypass the 65K method limit for Android applications. The new toolchain will hopefully decrease build times.

Given they they also produce a ton of Android apps, it seems like it's in their best interest to do this for themselves too.

Google has demonstrated time and time again that their developers are apparently willing to put up with a level of pain in terms of IDEs and build tools (and I'm tempted to complain about Java too) that gives me approximately zero confidence that their perception of what's best for them will coincide with making things easy.

I wonder. It seems like Google is more interested in building out on iOS these days.

Personal story that I'm basing that statement on: when I was applying to Google, I had 2 years of Android experience and 2 years of iOS experience before that. I told them I was more comfortable with Android given it was the most recent platform I worked with. They still insisted on me applying as an iOS engineer.

This obviously could be a supply issue; maybe they have plenty of Android engineers, but not enough iOS engineers?

Are the advantages of the new toolchain available anywhere?

From my understanding it's mostly about build times and maybe a bit of better code minification snuck in. The current gradle build process with the android gradle plugin is really slow for larger procjets. My last project took 15 seconds to compile hot and over a 1 minute to compile from cold start. This adds up when you need to make a build and see it on a device to make sure it looks right.

They are also making improvements to a UI editor/preview but that never replaces actually testing on a device. Speed to build is a big feature here.

Nice hedge against ultimately losing the copyright suit Oracle brought against you, Google.

Indeed, I seriously can't believe this is that high up the list of technical problems to resolve associated with Android dev.

Can you guys provide a little more background? I agree that this isn't an obvious priority, but I don't understand the reason that this would be considered a hedge.

It's not. The copyright case is about Google implementing Java standard library APIs, not anything about compilers/toolchains.

The compiler toolchains can sidestep the copyright issue by converting API calls into inline code, thus obviating the need to ship infringing API implementations with each Android device.

APIs are valuable IP. Oracle will fight hard to protect them, and even if the issue makes it to the Supreme Court, their victory is almost certain. Google needs an out if the Android platform is to survive; cutting Java out as early in the compilation process as possible is the best way to avoid infringement.

> APIs are valuable IP

That's up to the courts to decide. People can only hope that they decide against this, else it becomes illegal to create porting layers. For example, wine (the program) would then be illegal.

I feel like if this is really their thought, the go 1.4 release with support for Android seems more useful.

Reply on news.ycombinator.com