Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Java Programming News

JavaScript JVM Runs Java 234

mikejuk writes "The world of software is made slightly crazy because of the huge flexibility within any computer language. Once you have absorbed the idea of a compiler written in the language it compiles, what else is there left to gawp at? But... a Java Virtual Machine JVM written in JavaScript seems like another level of insanity. A lone coder, Artur Ventura, has implemented a large part of the standard JVM using JavaScript and you can check the code out on Github. Notice this isn't a Java to JavaScript translator but a real JVM that runs byte code. This means it could run any language that compiles to byte code." Bonus: on Ventura's website is a set of visual notes from a talk he gave titled "My Language Is Better Than Yours."
This discussion has been archived. No new comments can be posted.

JavaScript JVM Runs Java

Comments Filter:
  • by afabbro ( 33948 ) on Monday November 21, 2011 @02:34AM (#38121616) Homepage

    Javascript != Java. "Javascript" is just a naming rip-off. So what's the big deal?

    It's like writing a C compiler in Bourne shell. The point is less about the name than about the complexity and absurdity.

  • by sgt scrub ( 869860 ) <(saintium) (at) (yahoo.com)> on Monday November 21, 2011 @02:40AM (#38121632)

    The motivation for this effort is put very well in Artur's blog. He argues that rather than build JavaScript into web browsers they should have a virtual machine so that any language can be used. As well as this advantage, he also points out that with a JVM type approach you get automatic sandboxing and simply sending the JVM to the server provides browser independent persistence.

    I think it would have been easier to build a VM into a browser but I doubt it would have gotten this much attention. Still. It is a cool project.

  • by fsckmnky ( 2505008 ) on Monday November 21, 2011 @04:02AM (#38121880)
    ... you understand that a computer language, is a mapping of human readable symbols -> cpu instructions, either direct or indirect. If the mapping results in a set of cpu instructions that implements another language, you get another language.

    It's not rocket science people, its just math. Wait, maybe it is rocket science.
  • by devent ( 1627873 ) on Monday November 21, 2011 @04:11AM (#38121906) Homepage

    Yes, would make sense, wouldn't it? Instead that every browser have to interpret the slow JS language (yes, JS language is slow to interpret, because of the design choices. Just watch some of Doug Crockford videos), we could all just agree on a byte code standard like the Java byte code standard.

    Then you could develop web applications in your choice of language and not just in JS. On the server you upload just the byte code, like the compiled Java source code (.class).

    For example, you could develop in Ruby, Python or Java, and compile the code to the byte code for browsers. Then you deploy the byte code on the server.

    But the web-developers are so stubborn with their JS language, I don't know why.

  • Re:Javaception (Score:2, Insightful)

    by DrXym ( 126579 ) on Monday November 21, 2011 @05:12AM (#38122112)
    It couldn't either. Stuff like threads would be virtually impossible to do on Javascript, even with web workers. I suppose what it might do in the dim and distant future is allow tools like GWT to deploy jar files straight to web sites without any of the usual nonsense of translating Java source into umpteen variations of JS to cope with browser quirks.
  • Re:Javaception (Score:2, Insightful)

    by Anonymous Coward on Monday November 21, 2011 @05:21AM (#38122142)

    Not true! Since you're performing the execution of the byte code yourself you could implement the time slicing yourself. It wouldn't be easy sure - but it wouldn't be "virtually impossible". It'd all run within a single thread in the browser but emulating multiple threads in your JVM.

10.0 times 0.1 is hardly ever 1.0.