Hacker News Reader

Comment by dpratt | Hacker News Reader

I don't know the details of how this is implemented - I'm assuming that it's some sort of translation of JVM byte code to asm.js and a re-implementation of the core JDK runtime - but the question arises: why?

If you're still forced to use browser-based client-side Java applications, for whatever reason, what does this get you that just using the actual JVM plugin doesn't?

View on HN

Are you kidding? If that's really what this does, you've just properly sandboxed a horribly insecure binary plugin, eliminated the need to constantly install patches, heck, eliminated the need to even install a plugin whatsoever.

Its pretty hard to run an actual java applet nowadays. I think Chrome doesn't support it at all, Firefox may have also stopped supporting it. The Java applet plugin requires all code to be signed, and you can't disable that check, so if you have some legacy applet it is going to be quite difficult.

I believe this is for running non-browser applications in the browser.

Perhaps this could be a solution to avoid citrix or similar technologies if you have java apps only.

The JVM plugin will only run signed applets these days, which costs at least $200 or so.

Presumably this will allow people who have legacy unsigned applets a way out?

JVM byte code is translated to (highly optimized) vanilla, garbage collected JS (not Asm.js), moreover we provide a full build of the unmodified OpenJDK to guarantee compatibility with any application.

Security provided by the browser's vm instead of the system jvm?

Reply on news.ycombinator.com