

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
Can you run Doppio in Rhino on the JVM?

~~~
int3
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
You can have a go at EnvJS, dom support for Rhino

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

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

------
gouranga
Talk about abstraction!

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

Turtles all the way down...

~~~
alexandros
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
From a purely abstraction perspective that step makes sense. However it would
be omitted if we were talking about a run time stack.

------
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")})
        }

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

------
scanr
This is amazing.

doppio > rhino

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

hello world

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

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

------
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...](http://docs.oracle.com/javase/tutorial/uiswing/examples/start/HelloWorldSwingProject/src/start/HelloWorldSwing.java)

~~~
int3
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
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
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

