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

61–70 of 170 posts

Re: Mysterious Android codebase commit

#61

Post by pron »

bitmapbrother wrote: post #52
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…

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 dynamically load code at runtime or not. If not, that opens the door to some whole-program optimizations, or, at least, removes the need for guards, generated by the JIT, that are triggered when new code is loaded. In any case, mobile applications don't load code dynamically.

Re: Mysterious Android codebase commit

#62

Post by pron »

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).

Re: Mysterious Android codebase commit

#63

Post by lovelearning »

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.

Re: Mysterious Android codebase commit

#64

Post by pron »

ndesaulniers wrote: post #29
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. I can picture Google's lawyers using that in court against Oracle. > then the litigious organization issue might have been too That might is a big MIGHT, the same kind that keeps browser vendors from shipping various media codecs and news companies from using various media streaming protocols. > WebAssembly doesn't have a GC The GC all browsers currently have and will not get rid of…

> I can picture Google's lawyers using that in court against Oracle.

Google chose not to use OpenJDK (and they've obviously not complied with its license so far), so it being open source is irrelevant.

Re: Mysterious Android codebase commit

#65

Post by pron »

overgard wrote: post #25
grizzles wrote: post #9

Earlier quoted context omitted.

If this inference is right, I hope this means that Google will enable the web community to use the JVM with or as an alternative to WebAssembly. Hotspot is absolutely incredible technology, and it's competitors are still many years away from coming close to matching it's capabilities.

The only advantage I can think of to putting the JVM in a browser is if you intend to run java code. (God, I hope not). It's not like they're lighting the world on fire with their performance running dynamic languages. (I mean, it's fine, but it's nothing special) Besides, we already saw what java-in-the-browser looks like, and it was a huge failure.

> It's not like they're lighting the world on fire with their performance running dynamic languages. (I mean, it's fine, but it's nothing special)

Yes, they pretty much are[1], and yes, it is[2].

Their 80 kLOC JS compiler is on par with V8, they're matching or beating PyPy when running Python, and their Ruby performance is out of this world. The downside, though, is that it has a long warmup time, which makes it unsuitable for web pages.

[1]: https://www.youtube.com/watch?v=OUo3BFMwQFo

[2]: https://twitter.com/ChrisGSeaton/status/619885182104043520

Re: Mysterious Android codebase commit

#66

Post by rdtsc »

grizzles wrote: post #26
ndesaulniers wrote: post #18

Earlier quoted context omitted.

And throw out the hard work __ALL__ browser vendors are doing TOGETHER on WebAssembly? In favor of a VM that clearly has restrictions and is owned by a litigious organization? Bloating browsers by adding another VM, which will hurt throughput by having multiple GC's to synchronize? The JVM ecosystem and Hotspot are certainly modern marvels, but there's hurdles greater than the potential benefit.

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.

Re: Mysterious Android codebase commit

#67

Post by pron »

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.

OpenJDK has a full patent grant[1]. It is 100% open source in every way possible, its use is unrestricted, and it is released under the same license as Linux. AFAIK, Oracle has never sued anyone making use of it for whatever purpose whatsoever. It is important to remind the undisputed fact that -- at least so far -- Google has chosen not to use OpenJDK (or, in any case, they did not comply with its license), and therefore its open source status is irrelevant to the court case.

[1]: That grant is automatic, by the open source license. In addition (and unrelated to OpenJDK), there is an explicit patent grant to conformant implementations of Java (be they based on OpenJDK or not).

Re: Mysterious Android codebase commit

#68

Post by rdtsc »

pron wrote: post #67
rdtsc wrote: post #66

Earlier quoted context omitted.

> 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.

OpenJDK has a full patent grant[1]. It is 100% open source in every way possible, its use is unrestricted, and it is released under the same license as Linux. AFAIK, Oracle has never sued anyone making use of it for whatever purpose whatsoever. It is important to remind the undisputed fact that -- at least so far -- Google has chosen not to use OpenJDK (or, in any case, they did not comply with its license), and ther…

I see, good point.

I was saying in general, if something is released as open source, that doesn't usually come with a default immunity from patent litigation.

Re: Mysterious Android codebase commit

#70

Post by scrollaway »

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…

As a sidenote, giant commits including giant dependencies in the tree are the perfect time to include new backdoors. Nobody will know who really introduced them.

Wish people didn't do that. Separate repos are not hard to create...

Post reply on HN