11 ms·

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 abso

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.

0x0 11y ago
Embedding the JVM to run code within webpages you say? Hasn't that been tried before? :-S
devsquid 11y ago
I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.
- geofft 11y ago
  The 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.)
  - mike_hearn 11y ago
    The Java plugin's mistake was to have a crap auto update mechanism, and be politically unpopular because it wasn't open source. That's it. Both Firefox and Chrome ship massive numbers of security fixes with a high degree of regularity, but nobody cares, because: 1) It's the web, and The Web is close to religion for many people. 2) Their auto update mechanisms are pretty good, for Chrome, best in class, so people get the bug fixes. The JVM sandboxing mechanism itself isn't the issue. The design is sound. All sandboxes have escapes especially where native code is concerned, and JavaScript sandboxes have proven no different in this respect. The issue boils down to auto update (lack of).
ndesaulniers 11y ago
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.
- grizzles 11y ago
  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.
  - ndesaulniers 11y ago
    > 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.
overgard 11y ago
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.
- pron 11y ago
  > 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 https://www.youtube.com/watch?v=OUo3BFMwQFo [2]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520
comex 11y ago
> 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.
incepted 11y ago
This is a commit to the Android code base, what does this have to do with HotSpot, WebAssembly or even the JVM?

0x0 11y ago

Embedding the JVM to run code within webpages you say? Hasn't that been tried before? :-S

devsquid 11y ago

I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.

geofft 11y ago
The 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.)
- mike_hearn 11y ago
  The Java plugin's mistake was to have a crap auto update mechanism, and be politically unpopular because it wasn't open source. That's it. Both Firefox and Chrome ship massive numbers of security fixes with a high degree of regularity, but nobody cares, because: 1) It's the web, and The Web is close to religion for many people. 2) Their auto update mechanisms are pretty good, for Chrome, best in class, so people get the bug fixes. The JVM sandboxing mechanism itself isn't the issue. The design is sound. All sandboxes have escapes especially where native code is concerned, and JavaScript sandboxes have proven no different in this respect. The issue boils down to auto update (lack of).

ndesaulniers 11y ago

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.

grizzles 11y ago
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.
- ndesaulniers 11y ago
  > 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.

overgard 11y ago

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.

pron 11y ago
> 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 https://www.youtube.com/watch?v=OUo3BFMwQFo [2]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520

comex 11y ago

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

incepted 11y ago

This is a commit to the Android code base, what does this have to do with HotSpot, WebAssembly or even the JVM?