1) Gets an updated kernel
2) Can run standard JVM bytecode
3) Switches to CGroups
4) Allows for interop with desktop/server JVM
On a side note, I wish WebAssembly would just be JVM byte codes instead of this huge NIH syndrome. No need for the importing the Java SDK, broken sandbox mode, and all the other crap that made Applets fail... just the JVM itself.
It is unlikely that Android will run Java bytecode. The Dalvik runtime was aimed at keeping bytcode compact and interpreting faster than a JVM. ART is a pre-compiling (Dalvik bytecode to native) runtime. Using Java bytecode in the runtime on the Android device would open a whole big can of worms again. With open source APIs and no actual Java(tm) technology in an apk or on a device once code is translated from Java bytecode to Dalvik bytecode, Android stays clear of Oracle copyright claims.
You can actually load Java bytecode on Android (since 1.x!) by manually using a separate classloader at runtime[1]. There are even J2ME runners that have been doing that since Android's early days[2].
This would be great. The benefits of reuse of the toolchain and ecosystem alone are very compelling. That is another thing that will need to be reinvented by WebAssembly.
1) Gets an updated kernel 2) Can run standard JVM bytecode 3) Switches to CGroups 4) Allows for interop with desktop/server JVM
On a side note, I wish WebAssembly would just be JVM byte codes instead of this huge NIH syndrome. No need for the importing the Java SDK, broken sandbox mode, and all the other crap that made Applets fail... just the JVM itself.