3 ms·

I'd say never. That would kind of be like an apple switching to Swift for iOS. This is even harder for the Android runtime because it's run on a virtual machin

I'd say never. That would kind of be like an apple switching to Swift for iOS. This is even harder for the Android runtime because it's run on a virtual machine with characteristics that don't easily map to another language. Basically if they switch to any other language all the apps that currently use Java (ie. all of them) will have to practically use their own VM -which would be slow - or reprogram everything in another language - which would be expensive.

LoSboccacc 11y ago
Why would maintaining two runtime make dalvik app slower? They're all interpreted anyway.
- vetinari 11y ago
  They were JIT-ed for a while. That's what the "optimizing apps" modal dialog after updates is about.
  - sangnoir 11y ago
    >They were JIT-ed for a while. That's what the "optimizing apps" modal dialog after updates is about I think you meant AOT-ed. The language really doesn't matter though, as long as it can be converted to Dalvik bytecode.
    - vetinari 11y ago
      Yes, AOT-ed :)
- bobajeff 11y ago
  I was talking about the developer supplying their own VM on top of whatever the new runtime is going to be. However I suppose they could just add an extra one on the side. I wouldn't really consider that switching though.
merb 11y ago
Actually as a first step the language could be implemented on top of the dalvik vm. It's just that the IR of go would need to change for that target. Something like Truffle for OpenJDK could help by adopting new languages.
- bobajeff 11y ago
  That takes care of the language but none of the API's. I suppose that would be the second step. It sounds like this all would take a lot of time to complete. What would be the point for Google to do all this work?