DoppioVM: a JVM in CoffeeScript

[gmac]

http://int3.github.com/doppio/about.html

[int3]

I'm one of the authors. Doppio's not the first JVM in Javascript, but I believe we have the most extensive support for the JRE among the lot. In particular, we can run Rhino and the Java 4 compiler. Feel free to ask me any questions!

Check out the demo here: http://int3.github.com/doppio/

[nl → int3]

Can you run Doppio in Rhino on the JVM?

[int3 → nl]

I haven't tried, but I'm almost certain not -- Doppio relies on the existence of either the DOM or the Node API, and Rhino lacks both. Not to mention that our support for Rhino libraries isn't perfect as-is. Of course, one could write another shim layer for Doppio that uses the Rhino API... but I'm not going there :P

[inoop → int3]

You can have a go at EnvJS, dom support for Rhino

https://github.com/thatcher/env-js

[ntkachov → nl]

I don't personally like memes on HN but I believe this qualifies a "yo dawg".

[tlrobinson → int3]

Rhino on Doppoio on JavaScript has got to be the slowest thing in the world.

[vegas → tlrobinson]

I can't upvote this comment, but JVM is the greatest of all time.

[haileys]

I'm particularly impressed by this:

> While we do not emulate threads, we still wanted to handle blocking operations, particularly for standard input. Since the browser DOM is largely asynchronous, blocking operations have to be emulated via async callbacks. We solved this by implementing a 'yield' construct: upon encountering a blocking function, we throw a YieldException to pause the VM. This exception would also contain the asynchronous function that we are waiting on, which eventually calls the VM and resumes the program.

Absolutely brilliant work guys

[gildas]

We had browser sniffing, now we have jQuery sniffing :(

    function scrollToBottom() {
        jQuery.fn.jquery > "1.6" ? 
          inner.prop({scrollTop: inner.prop("scrollHeight")}) : 
          inner.attr({scrollTop: inner.attr("scrollHeight")})
    }

[gouranga]

Talk about abstraction!

Java -> bytecode -> JVM -> CoffeeScript -> JavaScript -> interpreter/JIT -> machine code -> CPU -> hardware.

Turtles all the way down...

[alexandros → gouranga]

I don't think the CoffeeScript step exists in the pipeline. CoffeeScript is the language the JVM is written in, but I don't expect it outputs CoffeeScript itself.

[ntkachov → alexandros]

From a purely abstraction perspective that step makes sense. However it would be omitted if we were talking about a run time stack.

[gouranga → alexandros]

There is the compilation of the JVM via CoffeeScript to Javascript. It's hard to illustrate that in text.

[grayrest → gouranga]

My first thought when reading this was the possibility of removing Clojurescript's compile time Java dependency.

[ntkachov]

Funny enough, Someone had told me about a grad student having to recreate the JVM in JavaScript at our school. Low and behold, the credits at the bottom of the page are for a few grad students at my school.

I think its a silly thing really, running a JVM on top of a JITer inside a browser. I can see it having some uses in specific cases but I can't imagine it being used for anything heavy duty.

[pooriaazimi → ntkachov]

It might be useful 5 years from now. There was another story a few weeks ago about Mozilla implementing a JavaScript interpreter inside JavaScript itself for security and sandboxing. This could lead to same thing. Although it's literally 100 to 200 thousand times slower than native code right now, but that might not be a big problem a few years from now (in the next few years we will probably see a huge increase of attention towards web app security).

Oh, and if this thing catches on, we won't be seeing another FlashBlock again :)

[int3 → ntkachov]

Indeed, it started out as a class project, but we're hoping to take it a lot further.

The plan is to implement a bytecode -> JS compiler next, a la JSIL / Emscripten. Thus far most of the work has gone into porting the runtime environment first.

P.S. I'm a sophomore, the other two are grad students :)

[jackcviers]

Cool project, guys!

Call me crazy, but I think threading could be implemented via green threading or by utilizing a global event loop to manage script execution. Using pop up windows, one for each thread, might also be a solution that takes advantage of system level threads. It might also be possible to implement sleep using a synchronous ajax call to someting that doesn't exist that has a specific timeout attached to it.

[haileys → jackcviers]

There's also the Web Workers API. 'Threads' can be run as workers which call back into the main event loop

[scanr]

This is amazing.

doppio > rhino

js> Packages.java.lang.System.out.println('hello world');

hello world

[jebblue]

A potentially cool concept, like GWT it lets me develop Java apps for the browser without touching JavaScript and without dealing with Applet signing issues like we used to have.

One problem though, I tried compiling the Swing Hello World app and after it worked at it for a while got a java.lang error:

http://docs.oracle.com/javase/tutorial/uiswing/examples/star...

[int3 → jebblue]

Yup, Swing isn't supported yet (graphical apps are going to take quite a bit more work). But we'll get there eventually!

[vegas]

Cheers guys, this is a project for which there is a clear and pressing need in the world of enterprise layer mediation.

I know that the observed real world running times are all sub-linear, but we can only theoretically proove that in runs in O( n * log(n) * log(n) * log (n) ) .

If you can maybe shave a log(n) off that running time proof, I'm sure that your thesis committee will finally have found big O, and we will make you an extra special hat to wear at graduation.

[francoisdevlin]

No. Just no.

The JVM is the only redeeming feature of Java (the language). You're nerfing the high performance features for what, exactly? A half assed tracing ability? "Write once, run anywhere"?

Javascript won in the browser, move on.

[davidrupp → francoisdevlin]

The JVM rose to prominence in the browser, and it was not always known for its "high performance features". Quite the opposite. Doppio is cool if for nothing else than to demonstrate that this is possible at all. I can't wait to see where the team gets once it can optimize for performance.

[adelevie]

Would this facilitate JRuby in the browser?

[Sanddancer → adelevie]

Probably, however, you're probably better off using emscripten (https://github.com/kripken/emscripten/, which uses the llvm backend and running ruby from there

[readme]

Amazing work, which gives me hope for my future dream...

Android in the browser.

[shotgun]

Spiffy!

[Bjartr]

I wonder what this means for GWT