4 ms·

> I hope they will pressure Android architects to replace dalvik with openjdk. Android hasn't used dalvik for ~5 years now. Switching from ART to OpenJDK runt

> I hope they will pressure Android architects to replace dalvik with openjdk. Android hasn't used dalvik for ~5 years now. Switching from ART to OpenJDK runtime is both non-trivial in complexity (can't break existing apps), and doesn't bring any obvious benefits, either. OpenJDK isn't tuned nor optimized for the constraints that Android operates in, and ART isn't exactly a slouch, either. The only benefit it brings in theory is just updated bytecode support, yet Android is still going to be stuck with dex, and still has the backwards & forwards compatibility issues, and OpenJDK doesn't help that situation at all. Nor have there been any significant bytecode changes/improvements in Java anyway, so you still don't get any benefits from it.

pron 6y ago
> Nor have there been any significant bytecode changes/improvements in Java anyway, so you still don't get any benefits from it. Java's core capabilities aren't just expressed as bytecodes -- there are lots of intrinsics, too, which, in this case, mean "native" capabilities exposed as library APIs but implemented in the VM and cannot be implemented in bytecode. Neither Panama nor Loom add or change any bytecode instructions, yet they drastically change the platform's core capabilities. Same goes for the module system -- it changes the accessibility/visibility rules in the VM but does add or change bytecode.
- kllrnohj 6y ago
  And not all of those enhancements are unique to OpenJDK. ART can already emit direct FFI calls from Java, for example ( https://android.googlesource.com/platform/art/+/86c8752f64629325026945cd4eabd1dcea224acb https://android.googlesource.com/platform/art/+/86c8752f6462... ) ART has also long had hooks for native allocations to influence GC pressure ( https://android.googlesource.com/platform/art/+/987ccff https://android.googlesource.com/platform/art/+/987ccff ) , which have improved to become automatic via malloc hooks & use phantom references for cleanup ( https://www.youtube.com/watch?v=7_caITSjk1k https://www.youtube.com/watch?v=7_caITSjk1k ) Similarly Loom isn't necessarily useful for client-side apps, as coroutines already fit that role and full green threads isn't useful. Most likely Loom would be a regression for mobile apps, as keeping key threads responsive is more important than maximizing throughput. And it definitely isn't going to be as tuned for things like big.LITTLE out of the gate as the existing Linux scheduler is. The only ~significant area of issue here is those trying to build commonly portable Java libraries. But there's not much in common in practice here, and that shouldn't be the singular deciding factor. But the meta-point here is how much of the "use openjdk instead!" crowd is simply overly familiar or buying in to OpenJDK hype & general JEP awareness, and simply isn't following along with what's going on with ART on the other side of things? ART isn't a bad runtime, after all, it's actually quite good. And it's had a lot of useful things that OpenJDK doesn't or only just recently got (like specifying what was null when an NPE is thrown - ART's been doing that for years)
  - pron 6y ago
    Sure, but my point was about similarity/compatibility. It might be the case that Android has suitable alternatives to Java's features, and it's possible that they're even more suitable for Android's needs, but the point is that while the two platforms were quite similar ten years ago, and a single language could target both with few if any tradeoffs, this is increasingly becoming tenuous as the two platforms become dissimilar in fundamental aspects. A language that attempts that will increasingly find itself needing to make tradeoffs that it didn't need to, say, five years ago, or even today.
  - thu2111 6y ago
    ART can indeed ignore Loom, or better just map the virtual thread API to regular threads. It'd not work well for things like generators but those aren't a target of Loom at the moment anyway. The lack of other features in ART does hold things back though. The list of bytecode and API features that ART doesn't have keeps growing and some would be useful on mobile. Panama will add a better FFI and a SIMD API, when will Android get that? Never? That would be a pity. What about Truffle/Polyglot? What about some of the neat tricks allowed by proper invokedynamic? Other than licensing I do wonder why Google can't just bring the nice bits of ART across to HotSpot. It would save library developers a lot of heartache.

pron 6y ago

> Nor have there been any significant bytecode changes/improvements in Java anyway, so you still don't get any benefits from it. Java's core capabilities aren't just expressed as bytecodes -- there are lots of intrinsics, too, which, in this case, mean "native" capabilities exposed as library APIs but implemented in the VM and cannot be implemented in bytecode. Neither Panama nor Loom add or change any bytecode instructions, yet they drastically change the platform's core capabilities. Same goes for the module system -- it changes the accessibility/visibility rules in the VM but does add or change bytecode.

kllrnohj 6y ago
And not all of those enhancements are unique to OpenJDK. ART can already emit direct FFI calls from Java, for example ( https://android.googlesource.com/platform/art/+/86c8752f64629325026945cd4eabd1dcea224acb https://android.googlesource.com/platform/art/+/86c8752f6462... ) ART has also long had hooks for native allocations to influence GC pressure ( https://android.googlesource.com/platform/art/+/987ccff https://android.googlesource.com/platform/art/+/987ccff ) , which have improved to become automatic via malloc hooks & use phantom references for cleanup ( https://www.youtube.com/watch?v=7_caITSjk1k https://www.youtube.com/watch?v=7_caITSjk1k ) Similarly Loom isn't necessarily useful for client-side apps, as coroutines already fit that role and full green threads isn't useful. Most likely Loom would be a regression for mobile apps, as keeping key threads responsive is more important than maximizing throughput. And it definitely isn't going to be as tuned for things like big.LITTLE out of the gate as the existing Linux scheduler is. The only ~significant area of issue here is those trying to build commonly portable Java libraries. But there's not much in common in practice here, and that shouldn't be the singular deciding factor. But the meta-point here is how much of the "use openjdk instead!" crowd is simply overly familiar or buying in to OpenJDK hype & general JEP awareness, and simply isn't following along with what's going on with ART on the other side of things? ART isn't a bad runtime, after all, it's actually quite good. And it's had a lot of useful things that OpenJDK doesn't or only just recently got (like specifying what was null when an NPE is thrown - ART's been doing that for years)
- pron 6y ago
  Sure, but my point was about similarity/compatibility. It might be the case that Android has suitable alternatives to Java's features, and it's possible that they're even more suitable for Android's needs, but the point is that while the two platforms were quite similar ten years ago, and a single language could target both with few if any tradeoffs, this is increasingly becoming tenuous as the two platforms become dissimilar in fundamental aspects. A language that attempts that will increasingly find itself needing to make tradeoffs that it didn't need to, say, five years ago, or even today.
- thu2111 6y ago
  ART can indeed ignore Loom, or better just map the virtual thread API to regular threads. It'd not work well for things like generators but those aren't a target of Loom at the moment anyway. The lack of other features in ART does hold things back though. The list of bytecode and API features that ART doesn't have keeps growing and some would be useful on mobile. Panama will add a better FFI and a SIMD API, when will Android get that? Never? That would be a pity. What about Truffle/Polyglot? What about some of the neat tricks allowed by proper invokedynamic? Other than licensing I do wonder why Google can't just bring the nice bits of ART across to HotSpot. It would save library developers a lot of heartache.