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

Comments

Not A New Concept

[DERoss]

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.

Re:Not A New Concept

[bucky0]

I feel like that sort of bootstrapping is normal. GCC's written in C, afterall.

Re:Not A New Concept

[Just Some Guy]

The JOVIAL J4 compiler was itself written in JOVIAL J4.

Want something really mind-blowing? PyPy is a Python interpreter written in Python. It includes a tracing JIT compiler to optimize hotspots as it runs to get about 5 times faster than the native C Python. I've used it and I still can't quite believe it.

DOM-Interface for byte code

[maweki]

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

Re:DOM-Interface for byte code

[martin-boundary]

I'd rather have source code than byte code. The web was built on visible code like HTML. Do you think it would have exploded if people couldn't look at the source to figure out how some neat web page was written?

Re:DOM-Interface for byte code

[the entropy]

How is what we have now with things like minified js any different than bytecode? Have a look at the source for gmail, or the minified version of jquery. You need analysis software to have any hope of making any sense of it and it's exactly the same then as a bytecode decompiler.

jQuery is open source, which means you can get the non-minified version and read that to know how it works, but I would dare anyone to make sense of the 100s of KBs of obfuscated js that is the gmail interface(or quite a few other popular products and services for that matter).

Problem is speed

[Anonymous Coward]

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.

Why now?

[thegarbz]

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?

Re:Javaception

[alexhs]

So you could [...] run the browser in itself?

Old news. Try chrome://browser/content/browser.xul in Firefox (doesn't seem to work as a clickable link, though).
See here for more options.

Re:Javaception

[Anonymous Coward]

If you don't care about the quality of your multithreading (and don't care if the whole thing just runs on one core of your multicore system), then writing threads into your JVM shouldn't be hard (assuming the hard part of writing the JVM has already been done, of course): Just have an interpreter for each thread (holding all thread-specific data), and then just cycle through all threads, letting each non-blocked one execute a fixed number of instructions before turning to the next (the interpreter class would have a method execute_instructions(number_of_instructions_to_execute) which would be called). Since, from the JVM's point of view, everything would run strictly synchronous, synchronization would not be an issue. Note that you'd not even use a timer.

Re:Javaception

[DrXym]

You'd have to use timers. The JS is running in a browser. If you let code for as long as it likes the browser won't be responsive and eventually will start complaining to the user about the fact. The JS would have to execute a bit of code, find some convenient point to halt, set a timer, drop out back to browser and then execute some more when the timer fired. Even if there was just one thread. When you have more than one thread you'd have to do the same for multiple threads via some kind of scheduler.

Re:Javaception

[Anonymous Coward]

A more interesting loop would be this:

Write Editor with Lisp interpreter in C. (check)
Write Browser with JavaScript interpreter in Lisp. (partial check -- I don't think w3 supports JavaScript)
Write JVM in JavaScript. (check)
Write x86 emulator in Java. (check)

Now run the editor on your x86 system, run the browser in that editor, run the JVM in that browser, run the x86 emulator in that JVM, repeat.

Re:Javaception

[Zortrium]

Warning: shameless self-promotion ahead: I've also written my own JVM interpreter in JavaScript, which supports a substantial amount (perhaps most?) of the standard JVM, including threading, synchronization, reflection, rudimentary I/O, and most of the standard library classes (e.g., HashMap and Random). There's a lot of hackery involved but it's totally doable.

Also, mine runs on Rhino, which is itself written in Java, so it's C (JVM) running Java (Rhino) running JavaScript (JSava, my interpreter) running Java (the user program). How's that for meta-execution?