Google dropped Jack compiler, how this will affect MOE?

1

As per the linked article google made it clear that they basically dropped support for Jack and Jill toolchain.

I’m not sure if this is a good or bad news for MOE.

On the good side I see working with standard javac an advantage, on the contrary I fell a lot of time was wasted by many projects that worked to support the now dead toolchain.

Will MOE be delayed by this?

2

Hi,

The development version of MOE 2.0 is currently based on Jack for the build system, so I wasn’t happy, when Google dropped the ball.

We already invested a lot in extending Jack to work for MOE (e.g. we are generating symbol export lists from Jack, and improved on the internal ProGuard implementation to work better for MOE). For these reasons, the first MOE 2.0 alpha will be based on Jack.

When we know more about Google’s actual plans (e.g. will they keep parts of the Jack backend where most of our changes are), we will make our own plans to migrate from Jack to the new toolchain.

However, Jack is kept as an internal implementation detail, so in later releases we will be able to transition to a different solution without any disruption for app developers.

Best Regards,
Gergely

2 Likes
3

Gergely, thank you for the update on Jack and MOE 2.0 plans

4

Dear kisg,
Then will MOE 2.x be released later than it’s original plan?
Will it be possible that MOE2.x divided two steps ?
First, MOE 2.x support Android N and MOE 2.0 will have a feature to generate precise ProGuard rules at runtime, make the app size small, like remove debug information, small size library, etc.
Second, bitcode support based on llvm?

After using the python script, the MOE 1.3.3 app size is near 40.5m (32bit), and 48.3m(64bit), the size is good now. And I think after generating precise ProGuard rules at runtime, removing debug information, using small size library, the app size can be smaller.

 Do you have a updated latest roadmap for MOE2.x now? 
 MOE1.3.x is really great, thank you very much!
5

Another issue is that Apple is planning to drop 32-bit devices in next iOS version and there seem to be a big issue with 64-bit simulators in MOE 1.3.x… and 2.0 will be able to produce a less cryptic debug info (stack traces I’m seeing on Crashlitics for my iOS app are not very informative)

It been said that 2.0 probably won’t have these issues, so I’m eagerly waiting for it now!