Slashdot Mirror
JavaScript JVM Runs Java
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."
So you could write a browser that supports JavaScript in Java, and then run the browser in itself?
... will be eventually written in JavaScript. ~ Atwood's Law (circa 2007)
Never trust a spiritual leader who cannot dance -- Mr. Miyagi
Forty years ago, a major software system for operating unmanned space satellites for the U.S. Air Force was written in a language called JOVIAL J4. The JOVIAL J4 compiler was itself written in JOVIAL J4.
Originally intended for a lifetime of 10-15 years, the system was actually in use for 20 years.
So we heard you like java...
...I heard you like Java in your script so I wrote you a JVM in Javascript so you can run Java while you're scripting.
Joking aside, this is not going to help the amount of confusion people have with regards to Java not being the same as Javascript *at all*.
The CB App. What's your 20?
For years I've been saying that we need a DOM-Interface for byte code in Browsers and everytime I get downvoted. Nice to see people exploring in these directions now.
"we do need DOM-Bindings for Bytecode now more than ever. It would be so great to write code in a language of my choice and compile it to Browser-Bytecode with DOM-Bindings. This would make it possible to deliver more proprietary code without making browser-plugins or something similar."
"What we really need are DOM-Bindings for Bytecode. So you can use every language you want that is capable of compiling to bytecode and send it to a browser. This would make it easier for the developer and bytecode is easier and faster for the browser to execute."
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.
Advice: on VPS providers
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.
Having to work for a living is the root of all evil.
Names have nothing to do with it. They could have just as well written their JVM in Python, Perl or PHP - except that none of those languages have undergone ten years of browser vendors fighting head to head to shave off another few microseconds on benchmarks, so their interpreters would be too slow to run an effective virtual machine.
I doubt that Javascript accelerators are good at optimizing this, but it's not fundamentally impossible to run it close to JVM speeds. JS is a language that in nutshell is self modifying code, so it can act as a translational layer which in the end enables running Java in a Javascript engine (interpreter,VM or whatever). It could be compared to Dart which also runs another type of language in JS.
... so I've put bloat in bloat, so you can wait while you wait.
This
This means it could run any language that compiles to byte code.
shoud read as
This means it could run any language that compiles to Java byte code.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
JVM is a run time environment not a compiler (although the environment includes a JIT compiler).
Also I think the point was javascript is seen as a less powerful language
null
... 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.
Fabrice Ballard already wrote an x86 emulator in javascript. Just install the standard x86 JVM inside of that and you're good to go.
I can see a use case: Once we have a mostly complete JVM interpreter with satisfactory performance written in Javascript, we can use any language that supports the JVM instead of Javascript.
(+1, Disagree)
Legit question from a programming novice: Why are all these discoveries coming up now? Hasn't JavaScript been around for 10+ years now? Is there something that has changed recently that makes people pursue these strange coding goals?
It's like writing a C compiler in Bourne shell. The point is less about the name than about the complexity and absurdity.
Isn't it more like writing a C compiler in C-shell - at least name-wise :-)
More like writing a Python interpreter in Perl. It'll work, but you'll feel a little dirty afterwards.
Actually, if the engine to run javascript is loaded from the website where your java app is downloaded from there is a much higher chance it will work.
It is what a lot of java programs already do, deliver their have their own JRE in a directory.
New things are always on the horizon
"Computers languages are how we tell computers what to do"
That's so in the past.
Nowadays, computer languages nowadays are (minus some exceptions) all about telling people what computers do.
I think aglider's point is that there exist notable bytecodes other than JVM bytecode, such as Microsoft CIL, UCSD p-code, Infocom Z-code, SCUMM bytecode, LLVM bitcode (which is already handled by Emscripten), and more.
Provided JavaScript is Turing-complete (and there are very few useful languages that aren't)
No language is Turing-complete because no machine has unbounded memory. A linear bounded automaton (LBA-complete) is a better model of computers that exist in the physical world.
Note the keyword here is possible. Desirable and practical are totally different matters altogether.
Especially because even once you've ignored speed, neither Turing completeness nor LBA completeness makes any guarantee about I/O capability.
That's a byproduct of Perl. What you write has nothing to do with it.