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

21–30 of 170 posts

Re: Mysterious Android codebase commit

#21

Post by blinkingled »

lovelearning wrote: post #20
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…

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.

Re: Mysterious Android codebase commit

#23

Post by cwyers »

blinkingled wrote: post #21
lovelearning wrote: post #20

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.

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

Re: Mysterious Android codebase commit

#25

Post by overgard »

grizzles wrote: post #9
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.

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.

Re: Mysterious Android codebase commit

#26

Post by grizzles »

ndesaulniers wrote: post #18
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.

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 browser for free. Not to mention the languages that have been statically compiled will run way faster than the equivalent JS. That would be great for mobile, and the spread of the open web.

Re: Mysterious Android codebase commit

#27

Post by ris »

ndesaulniers wrote: post #18
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.

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.

"a VM that clearly has restrictions and is owned by a litigious organization"

Indeed - if there's one thing that this case has shown it's that java is poison legally. If a company the size & power of Google is being forced to take a project the size & importance of Android places they really don't want to technically, well, that's a very big deal. And I wouldn't like to think what would happen to any smaller group that wanted to take a java technology down a path that isn't Oracle-approved.

Re: Mysterious Android codebase commit

#28

Post by comex »

grizzles wrote: post #9
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.

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.

> Hotspot is absolutely incredible technology, and it's competitors are still many years away from coming close to matching it's capabilities.

Especially when it comes to sandbox-escape security vulnerabilities! Among web technologies, HotSpot has historically beaten even Flash in that area.

Re: Mysterious Android codebase commit

#29

Post by ndesaulniers »

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.

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 that I was referring to was the JavaScript VM.

> It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does.

And the JVM doesn't have the start up performance of any JS VM. I would estimate the number of exploits to be significantly higher for the JVM, but worth less.

> Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the browser for free.

JS is the most compiled to language in existence. Also, my point has been none of this would be free. How do you integrate JVM with DOM? Who's going to rewrite all that? Who's GC cleans up around here?

> Not to mention the languages that have been statically compiled will run way faster than the equivalent JS.

Are you talking about WebAssembly here? Cause it sounds like you are.

Re: Mysterious Android codebase commit

#30

Post by ossreality »

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…

Are you fucking trolling us? Are you actually literally so young as to not remember Java Applets?

I don't think you have any idea of what you want, nor do you realize what you're asking for. You... want... WebAssembly.

Post reply on HN