4 ms·

It's how Java works. It is, indeed, how HTML, CSS, JavaScript, and many, many other technologies work (millions of us are all using the same Chrome browser that

by personZ 12y ago

It's how Java works. It is, indeed, how HTML, CSS, JavaScript, and many, many other technologies work (millions of us are all using the same Chrome browser that's doing exactly the same work to make sense of this markup, build and transform DOM trees, compile and JIT the scripts, etc. Why don't sites just serve up Chrome native code?). It isn't really "insane". There are benefits and detriments. Not least that the same APK can run on many Android versions, across many architectures (x86, AMD64, ARM, ARMv8, MIPS), with many different bits of system hardware. Further the whole "ART goes native" thing is largely wrong -- Dalvik already compiled to native, storing the JITted code for subsequent uses. ART is just a better performing, more considered rewrite.

pcwalton 12y ago
Well, what makes it kind of strange (IMHO) is that it's intermixed with native code via the NDK (which is heavily used by games, an enormous segment of mobile apps). So, in practice, the platform independence of Android isn't the same as that of the Web.
- personZ 12y ago
  is that it's intermixed with native code via the NDK Idiomatic use of the NDK is that you always provide Java surrogates for NDK functionality, but of course we know that isn't often the case. Instead developers can and do cross compile into a single APK. That is exactly what I do -- for my NDK components I build to x86 / ARM / MIPS (the last one I can never really justify) and it all goes into one APK. Alternately, and as a middle-grounds, I can make separate APKs for the platforms.
  - pcwalton 12y ago
    > Instead developers can and do cross compile into a single APK. So you lose the Web's ability to be retargeted to arbitrary architectures. You can only be retargeted to architectures that you compiled for. It's the exact same situation as in native code (because it is native code), and has very little in common with the Web's model (which can be retargeted to any architecture, even ones that Web authors didn't "cross-compile to"). By way of example, Nintendo could ship a Wii Browser (PowerPC), because JavaScript is platform independent. But Nintendo couldn't ship a Wii Android app runner and have it play games, because nobody compiles games for PowerPC.
    - personZ 12y ago
      It's the exact same situation as in native code Just to be clear, Android applications can be, and often are, 100% DEX (the vast majority of productivity, video, etc). Because, you hold, there are exception applications that break this model, the whole model is broken? It's saying that the web is broken because ActiveX is used somewhere. That is horribly specious. It is a dead-end argument by exception. But let's look at those uncommon apps that use some native code. a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. b) The majority of the NDK code will or should have Java equivalents. When the native code can't be used, DEX code will be used. Again, this is idiomatic. c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. In every case you benefit from the device specific compilation. So what doesn't hold again?
      - pcwalton 12y ago
        > But let's look at those uncommon apps that use some native code. Games are not exactly uncommon apps: https://play.google.com/store/apps/collection/topgrossing?hl=en https://play.google.com/store/apps/collection/topgrossing?hl... > a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. Do games really bother to ship Java equivalents? I would be really surprised if they did. > c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. Yes, you can use emulators for native code too, but that's hardly a good user experience unless the games are old.
radicalbyte 12y ago
It's a solution for a different time: a time when the code was distributed, where it could theoretically run anywhere, and be installed from anywhere. In that world, distributing one "intermediate-VM blob" which was then compiled to native on the client made a lot of sense. Today, in the world of centralized app stores, there's an argument to be made for directly distributing compiled binaries as an optimization. It still makes sense to use an intermediate format as it allows the most compatibility (i.e. new hardware), but the app store itself could distribute binaries for known/supported handsets as an optimization (it wouldn't surprise me if it didn't already do this).
- personZ 12y ago
  By what possible perspective is that from "a different time"? Because Microsoft decided to distribute compiled .NET apps to Windows Phone? Is there some great advantage that Windows Phone gains from this? It certainly doesn't seem so. It's quite remarkable to read people talking about how insane this is, how it's a solution for a different time, etc, when it is working remarkably well (number of people complaining about on phone AOT/JIT time -- about 0. Number of people sure it must be some great issue -- too many). It seems to be a solution for this time.
  - radicalbyte 12y ago
    > By what possible perspective is that from > "a different time"? Because Microsoft decided > to distribute compiled .NET apps to Windows Phone? When Dalvik would have been designed, there wouldn't have been an App Store. The model for mobile development wasn't clear like it is today. I agree that it's a great solution: the AOT cost is, in practice, tiny. The flexibility (and, I expect, reliability) provided is with the cost.

by personZ 12y ago

pcwalton 12y ago

Well, what makes it kind of strange (IMHO) is that it's intermixed with native code via the NDK (which is heavily used by games, an enormous segment of mobile apps). So, in practice, the platform independence of Android isn't the same as that of the Web.

personZ 12y ago
is that it's intermixed with native code via the NDK Idiomatic use of the NDK is that you always provide Java surrogates for NDK functionality, but of course we know that isn't often the case. Instead developers can and do cross compile into a single APK. That is exactly what I do -- for my NDK components I build to x86 / ARM / MIPS (the last one I can never really justify) and it all goes into one APK. Alternately, and as a middle-grounds, I can make separate APKs for the platforms.
- pcwalton 12y ago
  > Instead developers can and do cross compile into a single APK. So you lose the Web's ability to be retargeted to arbitrary architectures. You can only be retargeted to architectures that you compiled for. It's the exact same situation as in native code (because it is native code), and has very little in common with the Web's model (which can be retargeted to any architecture, even ones that Web authors didn't "cross-compile to"). By way of example, Nintendo could ship a Wii Browser (PowerPC), because JavaScript is platform independent. But Nintendo couldn't ship a Wii Android app runner and have it play games, because nobody compiles games for PowerPC.
  - personZ 12y ago
    It's the exact same situation as in native code Just to be clear, Android applications can be, and often are, 100% DEX (the vast majority of productivity, video, etc). Because, you hold, there are exception applications that break this model, the whole model is broken? It's saying that the web is broken because ActiveX is used somewhere. That is horribly specious. It is a dead-end argument by exception. But let's look at those uncommon apps that use some native code. a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. b) The majority of the NDK code will or should have Java equivalents. When the native code can't be used, DEX code will be used. Again, this is idiomatic. c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. In every case you benefit from the device specific compilation. So what doesn't hold again?
    - pcwalton 12y ago
      > But let's look at those uncommon apps that use some native code. Games are not exactly uncommon apps: https://play.google.com/store/apps/collection/topgrossing?hl=en https://play.google.com/store/apps/collection/topgrossing?hl... > a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. Do games really bother to ship Java equivalents? I would be really surprised if they did. > c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. Yes, you can use emulators for native code too, but that's hardly a good user experience unless the games are old.

radicalbyte 12y ago

It's a solution for a different time: a time when the code was distributed, where it could theoretically run anywhere, and be installed from anywhere. In that world, distributing one "intermediate-VM blob" which was then compiled to native on the client made a lot of sense. Today, in the world of centralized app stores, there's an argument to be made for directly distributing compiled binaries as an optimization. It still makes sense to use an intermediate format as it allows the most compatibility (i.e. new hardware), but the app store itself could distribute binaries for known/supported handsets as an optimization (it wouldn't surprise me if it didn't already do this).

personZ 12y ago
By what possible perspective is that from "a different time"? Because Microsoft decided to distribute compiled .NET apps to Windows Phone? Is there some great advantage that Windows Phone gains from this? It certainly doesn't seem so. It's quite remarkable to read people talking about how insane this is, how it's a solution for a different time, etc, when it is working remarkably well (number of people complaining about on phone AOT/JIT time -- about 0. Number of people sure it must be some great issue -- too many). It seems to be a solution for this time.
- radicalbyte 12y ago
  > By what possible perspective is that from > "a different time"? Because Microsoft decided > to distribute compiled .NET apps to Windows Phone? When Dalvik would have been designed, there wouldn't have been an App Store. The model for mobile development wasn't clear like it is today. I agree that it's a great solution: the AOT cost is, in practice, tiny. The flexibility (and, I expect, reliability) provided is with the cost.