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

Javaception

[embolalia]

So you could write a browser that supports JavaScript in Java, and then run the browser in itself?

Re:Javaception

[linuxgeek64]

It doesn't implement that much of the standard JVM.

Re:Javaception

[DigiShaman]

Ouroboros?

Re:Javaception

[cb88]

Sun already did that with HotJava it supported javascript.

Re:Javaception

[afabbro]

10 Write Browser in Java

20 Write Javascript engine in Browser

30 GOTO 10

Re:Javaception

[game kid]

Now we just have to do all of that in a Minecraft map so the CPU collapses under its own virtual weight!

Re:Javaception

[Joce640k]

Ummmm, Java != Javascript.

I thought that bit of confusion was cleared up by now. I was wrong.

Re:Javaception

[TheInternetGuy]

Think before posting please.

Seriously, if we are going to put that kind of requirement on posters, I will probably have to cancel my slash dot account

Re:Javaception

[sydneyfong]

but it wouldn't be "virtually impossible"

Exactly. It'd literally be virtually possible if you control the whole virtual machine...

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

[StripedCow]

This is modded "funny", but actually this would be very useful. Because you could send the browser along with your HTML and be done at once with all browser-compatibility problems. Plus you could make browsers supporting other languages (e.g., Python, Haskell, you name it).

Of course javascript would not be the appropriate target-language for this (I guess, due to efficiency issues), but the idea in itself is very interesting. A better target-language would be closer to the machine (no closures, and no garbage collection); the NaCl project might actually be a better candidate.

I'm betting that somewhere, somebody is already writing a browser in NaCl.

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

[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?

Anything which can be written in JavaScript ...

[Musically_ut]

... will be eventually written in JavaScript. ~ Atwood's Law (circa 2007)

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

[afabbro]

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.

Hardly unusual. GCC is written in C.

This is not quite the same thing.

Re:Not A New Concept

[TheRaven64]

Most compilers work like that. The Java compiler is written in Java (as you discover when it crashes and you get a Java stack trace). Smalltalk was written in Smalltalk and even modern Smalltalk implementations like Pharo are written in Smalltalk. The typical trick is to write a small compiler for a subset of the language in another language and then use it to compile the rest of the compiler. For example, the core of the Squeak VM is written in a subset of Smalltalk that is fairly easy to translate to C. This is then translated to C and compiled with the target system's C compiler. You then have enough of the VM running for it to load the rest. Early Pascal compilers did the same. In the '70s, having the compiler written in the language was considered a test of whether something was a 'real' language (since then we've learned that languages that are good for writing compilers are not necessarily good for other things. Well, some of us have...)

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.

yo dawg

[Anonymous Coward]

So we heard you like java...

Hey Bro...

[bennomatic]

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

Re:Hey Bro...

[Mitchell314]

Of course there's a difference. Java is defined as the language that runs on top of javascript. This is simple, it's just a compiled language that runs atop of an . . . interpreted . . . of an interpreted . . . it's a compiled . . . it's a compiled language that runs on an interpreted . . . okay guys, really, what the fuck? I think I just heard the sound of part of the universe and a good chunk of logic spontaneously imploding. I'm going to go cry now, and thanks to these dipshits my tears will probably fall sideways upwards now.

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

[devent]

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

Re:This is nonsense.

[afabbro]

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.

Interesting mind set

[sgt scrub]

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.

Yo dawg, I heard you like bloat

[wye43]

... so I've put bloat in bloat, so you can wait while you wait.

Really?

[aglider]

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.

Not mind blowing when ...

[fsckmnky]

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

This is completely unnecessary.

[DamnStupidElf]

Fabrice Ballard already wrote an x86 emulator in javascript. Just install the standard x86 JVM inside of that and you're good to go.

Re:This is completely unnecessary.

[jenic]

Fabrice Ballard already wrote an x86 emulator in javascript. Just install the standard x86 JVM inside of that and you're good to go.

Yes, that's why this is completely unnecessary.

Re:This is completely unnecessary.

[Anonymous Coward]

Dammit, Fabrice Bellard keeps making me feel like I am as dumb as a plate of chicken.

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:Why now?

[sydneyfong]

Javascript speeds have increased greatly due to the reheated competition by browser vendors (it wasn't too long ago that the only thing really existed was IE6). Thus in the past 10 years, nobody in their right mind would expect a x86 emulator, a JVM etc. to be implementable in Javascript at tolerable speed.

In fact, few expect these "discoveries" to happen so soon and so quickly, but since somebody proved it possible to do crazy things on Javascript, everyone with too much time on their hands are jumping on board and having fun with these projects.

Re:This is nonsense.

[Adrian Harvey]

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 :-)

Re:This is nonsense.

[deniable]

More like writing a Python interpreter in Perl. It'll work, but you'll feel a little dirty afterwards.

Re:This is nonsense.

[Oligonicella]

That's a byproduct of Perl. What you write has nothing to do with it.