Live data from Hacker News

Mysterious Android codebase commit

android.googlesource.com

51–60 of 170 posts

Re: Mysterious Android codebase commit

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

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.

No. Variety breeds better products and WebAssembly is a pretty different thing from the JDK. You might as well say that web assembly competes with LLVM.

I don't see anyone adding Java back into the browsers, that ship probably sailed.

I also have a huge problem with the litigious nature of Oracle... However, this would mean that something was settled and might reduce the likelyhood of future lawsuits especially in regards to patents or copyright. WebAssembly didn't go thru that process which might mean that if it picks up some anonymous patent holder might start attacking it. It is vendor neutral though, which is both a plus and a legal liability as there is no single "responsible" entity.

Re: Mysterious Android codebase commit

#52

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.

Re: Mysterious Android codebase commit

#53

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.

> AOT is here to stay.

No it isn't. Read the source. ART has a JIT now.

Re: Mysterious Android codebase commit

#54

I'm curious about big commits like this one: In the context of the recent juniper attack where some unauthorized code was committed without anybody noticing for years, it seems like it would be easy to hide a backdoor in such a big commit. How do you go about checking the integrity of the code when you have so many files? 8902 files were changed, most added, and the commit says it's just importing openJDK files. Is t…

> ...recent cisco...

you mean juniper perhaps?

Re: Mysterious Android codebase commit

#55
post #54

I'm curious about big commits like this one: In the context of the recent juniper attack where some unauthorized code was committed without anybody noticing for years, it seems like it would be easy to hide a backdoor in such a big commit. How do you go about checking the integrity of the code when you have so many files? 8902 files were changed, most added, and the commit says it's just importing openJDK files. Is t…

> ...recent cisco... you mean juniper perhaps?

Woops... it's fixed!

Re: Mysterious Android codebase commit

#56

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…

[deleted]

Re: Mysterious Android codebase commit

#57

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.

[deleted]

Re: Mysterious Android codebase commit

#58
post #56

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…

[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 Hotspot is not a clear win. ART does AOT compilation (at least some of the time), is integrated with the system runtime (doing a compacting GC pass on app switch, for example), and interacts properly with Android's zygote-based start scheme. (It doesn't, for example, COW away all the memory benefits as a naive fork would.)

Both ART and Hotspot have pretty good code generators and allocators. There's no reason to support that the latter would be a better choice, technically, than the former. Google seems to agree, since ART development is ongoing.

Please read more about VM implementation schemes instead of continuing to make unfounded assertions (like "Java is based on the idea of a JIT" and "virtual method calls are slow without a JIT").

Re: Mysterious Android codebase commit

#59

I recall seeing a "libopenjdkjni" related review on android-review earlier today. It was just a makefile change though, no real code diff. Unfortunately I can't find the review anymore.

This one: https://android.googlesource.com/platform/libcore.git/+/aab9...

    -LOCAL_SHARED_LIBRARIES += libart libnativehelper libdl
    +LOCAL_SHARED_LIBRARIES += libopenjdkjvm libnativehelper libdl
Replacing ART with OpenJDK JVM?!?

Re: Mysterious Android codebase commit

#60

I'm curious about big commits like this one: In the context of the recent juniper attack where some unauthorized code was committed without anybody noticing for years, it seems like it would be easy to hide a backdoor in such a big commit. How do you go about checking the integrity of the code when you have so many files? 8902 files were changed, most added, and the commit says it's just importing openJDK files. Is t…

I like this thinking. Someone with a big export of code repos could do some automated diff/analysis on open-source code to find vendored imports that have been modified from upstream or is outdated to facilitate manual security audits.
Post reply on HN