Live data from Hacker News

Mysterious Android codebase commit

android.googlesource.com

41–50 of 170 posts

Re: Mysterious Android codebase commit

#41

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.

"libopenjdkjni" looks like someone slammed their hand in the keyboard.

Re: Mysterious Android codebase commit

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

Thanks for ruining my holiday season. What's the precedent situation if they do settle it? Is Oracle's latest victory binding even if the final resolution of the case isn't decided by the court?

Re: Mysterious Android codebase commit

#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 there are two possibilities for how N will work.

Option one is that Android stick with ART and replaces Harmony with OpenJDK: from a technical perspective, that wouldn't be the end of the world, especially since the Harmony implementation is rather inefficient.

Option two is that Google ports Hotspot to run on Android and, then has PackageManager convert dex bytecode back to Java bytecode on device. That would be awful, since ART is built for low-end devices and, well, Hotspot isn't.

In favor of option one is that Google is still developing ART. In favor of option two is Oracle being Satan incarnate.

I also wouldn't be surprised if Oracle has compelled Google to simply ship a copy of Hotspot, allowing developers to ship "authentic Java" APKs instead of dex-bytecode ones, with the two environments running in parallel, with two different zygotes.

Re: Mysterious Android codebase commit

#44

Earlier quoted context omitted.

Entire AWT and Swing API. Nuts indeed!

I'm starting to wonder if Oracle got them to go JCK. Would be a technically crappy development that serves little actual purpose. Or maybe something's cooking and we don't know yet.

Since Android's zygote does preloading of system classes and ART does precompilation to native code, I think having these many additional classes in the core is bound to have an adverse effect on app startup times and device memory consumption. I'm surprised they're doing this so sneakily.

Re: Mysterious Android codebase commit

#45
post #37

Earlier quoted context omitted.

1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to

>Many of the largest most popular AAA games use gc Like, actual GC and not smart pointers? I would like a list.

These days a great deal of game logic is scripted in a language with GC: C#, JS, and Lua mostly.

Re: Mysterious Android codebase commit

#47
Its exciting to see all the goodies from java sound finally coming in. I could care less about cobra though Im just glad we get better support for audio coding from java without having to resort to jni and the native layer in c/c++.

Re: Mysterious Android codebase commit

#48

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…

dang, want to change the headline from "mysterious commit" to "Google switches Android to OpenJDK"?

Re: Mysterious Android codebase commit

#49
post #37

Earlier quoted context omitted.

1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to

>Many of the largest most popular AAA games use gc Like, actual GC and not smart pointers? I would like a list.

https://wiki.unrealengine.com/Garbage_Collection_Overview

https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games

TSubobjectPtr are smart pointers, but regular pointers will still be garbage collected if they are UPROPERTY() and in a class derived from UObject

Tim Sweeny talks about GC a bit in https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...

The presentation is a little dated, but they're still using GC, so...

Re: Mysterious Android codebase commit

#50
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 there anybody checking that the source file imported haven't been modified to include some kind of backdoor?

edit: replaced "cisco" with "juniper"

Post reply on HN