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

71–80 of 170 posts

Re: Mysterious Android codebase commit

#71

Post by drtse4 »

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…

> Harmony implementation is rather inefficient.

A lot of stuff have been fixed or improved from the original Harmony code over the years, performance-wise the android implementation of the core library and the openjdk implementation are now similar (openjdk has a few more intrinsics and makes a more liberal use of native methods).

Re: Mysterious Android codebase commit

#72

Post by icebraining »

Ambroos wrote: post #69
bluesilver07 wrote: post #46

Change dependency from libart -> libopenjdkjvm. Does this mean they're discarding ART for OpenJDK's VM?

It could. Not a bad thing, the HotSpot VM in OpenJDK is incredibly fast.

Does that hold on 32-bit ARM CPUs with 1GB of RAM?

Re: Mysterious Android codebase commit

#73

Post by drtse4 »

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…

> But what I don't understand is why they're importing the full AWT API!

Some really old and completely unrelated non-awt classes depend on interfaces defined in java.awt. But in this case it simply seems a mass import.

Re: Mysterious Android codebase commit

#74

Post by drtse4 »

Ambroos wrote: post #69
bluesilver07 wrote: post #46

Change dependency from libart -> libopenjdkjvm. Does this mean they're discarding ART for OpenJDK's VM?

It could. Not a bad thing, the HotSpot VM in OpenJDK is incredibly fast.

> the HotSpot VM in OpenJDK is incredibly fast.

True, but only on x86.

Re: Mysterious Android codebase commit

#75

Post by pjmlp »

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 few hundred KBs, not a few hundred MB like Android.

Re: Mysterious Android codebase commit

#77

Post by mirsadm »

Ambroos wrote: post #69
bluesilver07 wrote: post #46

Change dependency from libart -> libopenjdkjvm. Does this mean they're discarding ART for OpenJDK's VM?

It could. Not a bad thing, the HotSpot VM in OpenJDK is incredibly fast.

It does seem bizarre that Google would put in all the effort to develop ART and then retire it so quickly.

Re: Mysterious Android codebase commit

#78

Post by grizzles »

pron wrote: post #62
grizzles wrote: post #6

To explain if you are just joining in: This pretty much means Oracle v Google, a case with major ramifications for the industry has been settled out of court. I don't see how this can be interpreted any other way.

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 commit. Someone please post if I'm wrong about this.

Re: Mysterious Android codebase commit

#79

Post by lmm »

rdtsc wrote: post #66
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…

> The JVM is already open source. From what I understand open source and imunity from litigation are orthogonal. Open source code and still be a patent minefield.

All code can be a patent minefield. I predict we'll see patent trolls going after browser makers as soon as WebAssembly becomes popular. The fact that Java has a single, notoriously litigious owner actually works in its favour here - anyone trying to patent-troll Java will be issuing an invitation to Oracle's attack dogs, whereas WebAssembly could easily suffer a tragedy of the commons where no one browser vendor wants to spend the money to defend it.

Re: Mysterious Android codebase commit

#80

Post by Ded7xSEoPKYNsDd »

pron wrote: post #61
bitmapbrother wrote: post #52

Earlier quoted context omitted.

Option two wasn't even worth mentioning. There is absolutely no way Google is going to abandon ART and switch to a significantly less performant VM. AOT is here to stay.

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.

Post reply on HN