Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mysterious Android codebase commit

android.googlesource.com

Post reply on HN
Print view View original

81–90 of 170 posts

Re: Mysterious Android codebase commit

#81

Post by pron »

grizzles wrote: post #78
pron wrote: post #62

Earlier quoted context omitted.

Or that Google has simply decided to use OpenJDK and abide by its license, an option that has always been open to them (yet they have so far rejected).

This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. But the NOTICE file doesn't say anything about Oracle at all! Nor did they carry over the openjdk LICENSE file, which adds to the mysteriousness. I only did a cursory examination of the c…

> GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache.

That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by the OpenJDK license -- so in this case, the whole runtime minus Google-only packages if they're classpath-linked only.

My thought was that Google may simply choose to make Android GPL + classpath exception. The reason for not doing so when Android was young (I can only assume) was the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes (of course, Linux doesn't either, but I guess the thought was that the phone manufacturers are likely to make changes that are closer to the application). But now, given Android's popularity, phone vendors would swallow whatever license Google imposes on them (and would still be free to make proprietary changes to classpath-linked portions of the runtime).

This is a win for everyone: Google gets to expend less effort maintaining the runtime, plus they get Oracle off their back (at least for future Android versions); Oracle gets to have Java (or something close enough to it) on lots of smartphones, and the developer community gets to have true Java interop (with all new Java features), and probably a higher-quality runtime.

Later, Google would be free (but not compelled, although that depends on a future settlement) to make Android fully Java compliant with one of the Java standards, but that is an orthogonal issue.

Re: Mysterious Android codebase commit

#82

Post by pron »

Ded7xSEoPKYNsDd wrote: post #80
pron wrote: post #61

Earlier quoted context omitted.

A JIT makes many tradeoffs but it is always capable of producing code at least as good as an AOT. How much better that code is depends on many factors, such as the language, the application, and how much time/energy you're willing to spend on optimization (the latter might lead to choosing to generate code that's less optimized than an AOT). A slightly bigger difference is not between JIT and AOT, but whether you can…

> the latter might lead to choosing to generate code that's less optimized than an AOT With ART compilation happening on the device (during installation instead of runtime, but still) it suffers of the same trade-off of compilation performance vs. performance of the generated code. > In any case, mobile applications don't load code dynamically. Android has a DexClassLoader. I'm sure some people use it.

> it suffers of the same trade-off of compilation performance vs. performance of the generated code

Sure, which is why HotSpot may be better.

> Android has a DexClassLoader. I'm sure some people use it.

I didn't know that (not an Android dev), but that only means that some form of JITting may be beneficial anyway (depending on how popular this feature is).

Re: Mysterious Android codebase commit

#83

Post by pron »

pcwalton wrote: post #39
grizzles wrote: post #26

Earlier quoted context omitted.

The JVM is already open source. If this matter has indeed been settled, then the litigious organization issue might have been too. WebAssembly doesn't have a GC, and probably won't for some time. It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the brows…

> WebAssembly probably won't [have a GC] for some time Citation needed :) > It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. JS engines have been tuned very well over the years. Remember that Web Assembly is designed to run in a JS engine.

> Remember that Web Assembly is designed to run in a JS engine.

Is it? It's a very low-level bytecode that's designed to be efficiently compiled in one pass, and completely unrelated to the JS engine. It isn't meant (at least at this time) to have an optimizing JIT (like HotSpot or V8). It is meant as a good target for languages that don't rely on/can't benefit greatly from good JIT optimizations, such as C/C++ (or Rust).

Of course, one could compile a JVM to wasm, provided that wasm allows applications to write to executable memory (which I doubt).

Re: Mysterious Android codebase commit

#84

Post by logicchains »

pron wrote: post #81
grizzles wrote: post #78

Earlier quoted context omitted.

This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. But the NOTICE file doesn't say anything about Oracle at all! Nor did they carry over the openjdk LICENSE file, which adds to the mysteriousness. I only did a cursory examination of the c…

> GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by…

Barely on topic, but since you're the person to ask, would the use of OpenJDK on Android mean that it'd support Pulsar/Quasar?

Re: Mysterious Android codebase commit

#85

Post by crustycoder »

quotemstr wrote: post #58
[deleted] wrote: post #56

Earlier quoted context omitted.

[deleted]

You're confused on several points. First, Java VMs don't "generate bytecode": if they have JITs, they generate machine code. Otherwise, they just interpret bytecode. Second, you're confusing OpenJDK-the-set-of-libraries with Hotspot-the-VM. OpenJDK probably isn't a disaster for performance: not because it's good, but because Harmony was abysmal. (Count the allocations inside String.format.) Switching from ART to Hots…

"(It doesn't, for example, COW away all the memory benefits as a naive fork would.)"

That's not the case any longer, posix_spawn() is used on recent JVMS rather than fork().

Re: Mysterious Android codebase commit

#86

Post by makomk »

pjmlp wrote: post #75
quotemstr wrote: post #43

This diff is more explicit about what's going on: https://android.googlesource.com/platform/libcore.git/+/aab9... Change dependency from libart -> libopenjdkjvm. There are also diffs adding lambda support, tweaking various classes for compatibility with applications that use reflection to access internal capabilities, and fixing lots OpenJDK compatibility bugs. Android still needs to run dex bytecode somehow , so the…

> That would be awful, since ART is built for low-end devices and, well, Hotspot isn't. That is plain Google FUD to not follow the Java standards. There are lots of embedded devices, more constrained than Android phones, running commercial compliant JVMs like Atego, Jamaica, J9 among many others. Also Sun/Oracle Hotspot implementations have existed since the J2ME and Embedded Java early days for devices with just a f…

I'm pretty sure those constrained devices are running bytecode interpreters that aren't nearly competitive with native code in terms of speed, with UIs that wouldn't cut it on even a low-end smartphone these days.

Re: Mysterious Android codebase commit

#87

Post by blinkingled »

lovelearning wrote: post #63
blinkingled wrote: post #15

The commit references ojluni. This relates to "luni" in Android source which stands for lang util net io. Sounds like there are plans to replace the harmony implementation with OpenJDK one. License differences are definitely interesting but could be also related to performance and completeness - luni is fairly small set of classes whereas ojluni import brings in a ton more. But what I don't understand is why they're…

I took a closer look at the commits, and I think it's not as bad as it looked at first. They imported all classes of OpenJDK in the February commit posted here, but then removed things like Swing at some later point of time. It's not there in the master now.

Oh cool, so just a new libcore implementation based on openjdk, which should be a good thing actually.

Re: Mysterious Android codebase commit

#88

Post by pron »

logicchains wrote: post #84
pron wrote: post #81

Earlier quoted context omitted.

> GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by…

Barely on topic, but since you're the person to ask, would the use of OpenJDK on Android mean that it'd support Pulsar/Quasar?

Hmm, this may be orthogonal, but it certainly can't hurt. Quasar already has AOT instrumentation and we're working on making it available on Android as-is. OTOH, even if Android goes OpenJDK, it's doubtful they'll support agents, so you'll have to rely on AOT instrumentation anyway.

But to get us back on point, it will certainly make the work of migrating any Java library to Android easier.

Re: Mysterious Android codebase commit

#89

Post by pjmlp »

makomk wrote: post #86
pjmlp wrote: post #75

Earlier quoted context omitted.

> That would be awful, since ART is built for low-end devices and, well, Hotspot isn't. That is plain Google FUD to not follow the Java standards. There are lots of embedded devices, more constrained than Android phones, running commercial compliant JVMs like Atego, Jamaica, J9 among many others. Also Sun/Oracle Hotspot implementations have existed since the J2ME and Embedded Java early days for devices with just a f…

I'm pretty sure those constrained devices are running bytecode interpreters that aren't nearly competitive with native code in terms of speed, with UIs that wouldn't cut it on even a low-end smartphone these days.

Then you should educate yourself, as they are running JIT and AOT code.

I can provide links for product documentation and real products if you wish.

Re: Mysterious Android codebase commit

#90

Post by Nitramp »

pjmlp wrote: post #89
makomk wrote: post #86

Earlier quoted context omitted.

I'm pretty sure those constrained devices are running bytecode interpreters that aren't nearly competitive with native code in terms of speed, with UIs that wouldn't cut it on even a low-end smartphone these days.

Then you should educate yourself, as they are running JIT and AOT code. I can provide links for product documentation and real products if you wish.

pjmlp: original poster above referred to Hotspot, not arbitrary JVMs. Clearly Android devices can run VMs with both JIT and AOT (they do, after all), what OP questioned was whether Hotspot in particular (not some arbitrary VM) is a good VM on a mobile device. Given Hotspot's somewhat underwhelming startup speed even on desktop class computers, I think that's a very reasonable technical question to ask, and not FUD in any way.
Post reply on HN