16 ms·
Mysterious Android codebase commit
- mahouse 11y agoWhat's mysterious? Legit curious.
- aasdh 11y agonothing. Just to make it more curious. :#
- hoodoof 11y agoCan't you see? It's obvious. Chariots Of The Gods, man. Aliens are everywhere including git.
- wmf 11y agoGoogle has made a point of not using GPLed code (except Linux) or Sun/Oracle code in Android, for technical and legal reasons. There's even a lawsuit about it. So it's surprising to see GPLed Oracle OpenJDK code being committed anywhere near Android.
- exabrial 11y agoInteresting, isn't Android ASL?
- grizzles 11y agoTo 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.
- 0x0 11y agoAlso, why are the two timestamps so far off? Authored in February 2015 (almost a year ago!), but committed only in Nov 2015.
- temac 11y agoMaybe because this has been ready for a long time just in case and they just decided to actually switch to that strategy right now?
- deathanatos 11y agoThis is a git repo, so "authored" tries to map to the person who wrote the content, and the "idea" of the commit, if there is such a thing. It's set when the commit is initially created, and for the most part not changed unless explicitly requested. The commit date is the actual time the commit object was made; this can differ if the commit is amended, rebased, cherry-picked, the result of a squash/fixup, etc. If a commit sits on a branch for months, then gets rebased against master, code-reviewed, and merged, those two dates will be significantly different. This usually works as you might expect. If your coworker Joe authors a commit on a branch, and you cherry-pick it onto another branch, that cherry-picked commit is authored by Joe (and the time reflects when Joe authored it) and commited by you (at the time you performed the cherry-pick).
- saurik 11y agoFirst, read my response to the other person who provided a technical answer to this question. https://news.ycombinator.com/item?id=10806642 https://news.ycombinator.com/item?id=10806642 You have gone a little further and provided some general reasons as to "why this might happen", but you still seem to have missed the essence of the question, which was almost certainly more "can someone come up with some guess why, in this particular circumstance, given the theories about this commit being influenced by a settlement of the Oracle lawsuit, this commit was authored in February but only landed in November?".
- deleted 11y ago[deleted]
- kazinator 11y agoThis means that a person named Piotr Jastrzebski created a commit in February. This is a different commit based on that one (not in the sense of revision ancestry, but in the sense of rewrite history): this commit is the N-th rewrite of Piotr's Jasterbski's commit, for some N > 0, and the rewriter ("committer") is Narayan Kamath. The rewrite can have different content: for instance, it can be altered to merge against a different parent. An example of a rewrite is a simple cherry-pick (e.g. from one branch to another). All these things are commits. The initial authoring is a commit, and this latest rewrite by a different person is a commit.
- grizzles 11y agoIf 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.
- 0x0 11y agoEmbedding the JVM to run code within webpages you say? Hasn't that been tried before? :-S
- devsquid 11y agoI'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.
- geofft 11y agoThe Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this single line of defense between untrusted code and full local privileges just like native code. And, like anything with a complicated security policy and a wide attack surface, it had no chance. Stick a regular, unprivileged JVM, with no secure classloader magic, inside a straightforward non-Java low-level sandbox like NaCl or even just PPAPI + Chrome's renderer sandboxing (like Pepper Flash or PDFium) and it'll probably hold up just fine. And honestly that's what Android does. Java isn't a security boundary on Android, and the NDK makes this explicit. Each app runs as its own UID, and the kernel is taught to isolate users a bit more than usual for UNIX, and that holds up pretty well -- not perfect, but far better than the Java plugin does. (To be clear, I'm not advocating the JVM as a platform for web content. Just that, if somehow it turns out that the JVM is in fact the right platform, the sandboxing problem not a blocker.)
- 11y ago
- rewqfdsa 11y agoThanks 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?
- curt15 11y agoThe federal circuit's opinion concerning the copyrightability of APIs is only binding precedent on the federal circuit itself and only when interpreting 9th circuit law. The FC's usual jurisdiction is over patents, not copyrights, and they only got involved in this case because Oracle originally asserted some patents that failed to find traction. In particular, the real 9th circuit would be free to draw their own conclusions should they hear a future case concerning the copyrightability of interfaces.
- pron 11y agoOr 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).
- grizzles 11y agoThis 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.
- pron 11y ago> 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.
- rogerthis 11y agoMaybe related: http://mail.openjdk.java.net/pipermail/announce/2015-September/000200.html http://mail.openjdk.java.net/pipermail/announce/2015-Septemb...
- blinkingled 11y agoThe 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 importing the full AWT API! That's nuts.
- lovelearning 11y agoEntire AWT and Swing API. Nuts indeed!
- blinkingled 11y agoI'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.
- cwyers 11y agoIIRC, Oracle's claim was that Google's use of the API wasn't fair use because they didn't implement all of it; they weren't trying to build a compatible product. So importing enough of Java to be fully compatible might be a result of the lawsuit, yeah.
- lovelearning 11y agoSince 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.
- lovelearning 11y agoI 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.
- aaronkrolik 11y agoDoes this mean no more DVM?
- LukeB_UK 11y agoDalvik was replaced by ART in Lollipop
- jevinskie 11y agoI 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.
- donatj 11y ago"libopenjdkjni" looks like someone slammed their hand in the keyboard.
- maik 11y agoThis one: https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0%5E%21/#F0 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?!?
- jevinskie 11y agoThis is the one I was thinking of: https://android-review.googlesource.com/#/c/193835/ https://android-review.googlesource.com/#/c/193835/ It was 'libopenjdkjvm' not 'libopenjdkjni' as I recalled.
- dbwest 11y agoI was hoping this would be a link to code committed by AI. More of those, please?
- quotemstr 11y agoThis diff is more explicit about what's going on: https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0 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.
- quotemstr 11y agodang, want to change the headline from "mysterious commit" to "Google switches Android to OpenJDK"?
- bitmapbrother 11y agoOption 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.
- quotemstr 11y ago> AOT is here to stay. No it isn't. Read the source. ART has a JIT now.
- invalidname 11y ago
- bluesilver07 11y agoChange dependency from libart -> libopenjdkjvm. Does this mean they're discarding ART for OpenJDK's VM?
- Ambroos 11y agoIt could. Not a bad thing, the HotSpot VM in OpenJDK is incredibly fast.
- icebraining 11y agoDoes that hold on 32-bit ARM CPUs with 1GB of RAM?
- drtse4 11y ago> the HotSpot VM in OpenJDK is incredibly fast. True, but only on x86.
- mirsadm 11y agoIt does seem bizarre that Google would put in all the effort to develop ART and then retire it so quickly.
- shams93 11y agoIts 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++.
- gouggoug 11y agoI'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"
- signa11 11y ago> ...recent cisco... you mean juniper perhaps?
- gouggoug 11y agoWoops... it's fixed!
- lunixbochs 11y agoI 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.
- ZoFreX 11y agoThe same way I validate scary merge commits: Do it myself, and compare what I get to what they got.
- merb 11y agoSo Lambda's are finally comming
- ph0o 11y agooh, i hope so!
- bitmapbrother 11y agoOn a tangential note, I guess this means Android is finally getting Java 8 support as well as Java 9, 10, 11, etc