
Doppio: JVM written in JavaScript - api
http://plasma-umass.github.io/doppio-demo/
======
brad0
This is cool. Not because it's useful or performant etc. but because it shows
how simple java bytecode is.

After seeing this I wanted to know:

\- how many opcodes exist in the JVM

\- how easy would it be to create another language that compiles to the JVM.

\- how does the JVM represent basic data types

The list goes on. All because someone built a JVM in JS.

What happened to the hacker mentality of HN? Where's the curiosity gone?

~~~
winter_blue
This. I don't think enough people appreciate how the simple and clear the JVM
byte code's design is.

Most platforms in use today are so complex. Take a look at x86, or one of the
latest ECMAScript specifications. Even LLVM bitcode is a bit complicated
compared to the JVM bytecode.

I think in programming language research, going forward, we need some research
into "high-level bytecodes". I.e. bytecodes that capture high-level concepts
in a clear and simple way.

~~~
jdmichal
I've actually found CIL to be simpler than JVM bytecode, even with additional
capabilities. Simple addition is a good example:

JVM: dadd, fadd, iadd, ladd. Addition for double, float, int, and long data,
respectively.

CIL: add, add.ovf, add.ovf.un. Addition, signed addition with overflow check,
and unsigned addition with overflow check.

~~~
bad_user
Those bytecodes happened because the JVM bytecode was designed to be easily
interpreted, whereas CIL was designed for JIT compilation. So for example
CIL's `add` opcode is missing info that needs to come from the context in
which it is used and the JVM's `iadd` and variations are easier to interpret.

You can see this design choice even today in how the JVM and CLR work. The JVM
starts execution in an interpreter mode, then gradually compiles pieces of
code as it detects bottlenecks. So the compilation that happens at runtime is
very gradual and based on runtime measurements.

The CLR on the other hand has done JIT compilation, with the ability to cache
the compiled code for faster startup (e.g. Ngen). So it has been oriented
towards ahead of time compilation.

Different trade-offs.

~~~
jdmichal
Sure. I tried to find information yesterday when I posted that regarding
whether / how the `add` code handles differing types. Now since I'm not on my
phone, I looked up the ECMA spec and it looks like CIL still only allows like
types, with some minor exceptions involving `native int`. So it's just up to
the compiler to make sure that actually happens and extend types as necessary.

------
apignotti
If you like Doppio JVM, you may find our project interesting too
[http://blog.leaningtech.com/2017/06/announcing-cheerpj-
java-...](http://blog.leaningtech.com/2017/06/announcing-cheerpj-java-
compiler-for-webapps.html). Our approach is to rely heavily on AOT compilation
of JARs to JS to achieve higher perf, while still supporting full reflection.
Moreover the RT is automatically split to reduce download time and bandwidth.
A Swing application starts with ~15MB on our system.
[http://cheerpjdemos.leaningtech.com/SwingDemo.html](http://cheerpjdemos.leaningtech.com/SwingDemo.html)

~~~
emeryberger
Also, see our follow-on project, Browsix
([http://browsix.org](http://browsix.org)), which makes it possible to run
Unix applications inside the browser.

------
cobookman
So now you can run the JVM in JavaScript running in the JVM....

For those who don't know the JVM comes with a JavaScript engine by default:
[http://www.oracle.com/technetwork/articles/java/jf14-nashorn...](http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html).
And you can even get v8/nodejs to be compiled in your java jar binary:
[https://github.com/eclipsesource/J2V8](https://github.com/eclipsesource/J2V8)

~~~
Capt-RogerOver
This is very cool. You can basically even call all Java classes (and the other
way around) from that JavaScript! (And reliably limit the classes that can be
used if you want to execute JS in a safe environment.) Why isn't this used
more often? (Or is it used more often?)

~~~
cderwin
I can't speak to whether it is used more often, but I would bet the java-based
Nashorn vm is significantly slower than the c++-based nodejs. In fact, a
cursory google search shows this is the case, and it's not even close.

See: [http://blog.jonasbandi.net/2014/03/performance-nashorn-vs-
no...](http://blog.jonasbandi.net/2014/03/performance-nashorn-vs-node.html)
[http://pieroxy.net/blog/2015/06/29/node_js_vs_java_nashorn.h...](http://pieroxy.net/blog/2015/06/29/node_js_vs_java_nashorn.html)

(I can't speak to the quality of either of these tests, but the results seem
decisive)

~~~
Capt-RogerOver
While it is of course going to be slower, "it's not even close" is a judgement
claim. The tests you have link talk about 1.6-2-3 times the difference. In a
lot of applications the performance hit is going to be worth gaining access to
the whole Java ecosystem of libraries. Also the performance is very likely to
increase with newer versions.

------
sandGorgon
I think it is impolite not to give accurate credit. It is Typescript... and
not vanilla javascript.

[https://github.com/plasma-umass/doppio](https://github.com/plasma-
umass/doppio)

~~~
rounce
May as well write Java.

~~~
mercer
How so?

~~~
thangngoc89
Use Java to create bytecode which is executed in JS to produce JVM bytecode

------
Scarbutt
Impressive, loaded a clojure.jar, got a repl and wrote/called some silly
functions, it worked...

~~~
amelius
Of course, the Java bytecode has only a limited number of instructions.

------
fredley
I would like to run this in Rhino[1] - Mozilla's Javascript engine written in
Java - just because. Turtles all the way down...

[1]: [https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/Rh...](https://developer.mozilla.org/en-
US/docs/Mozilla/Projects/Rhino)

------
ianopolous
I investigated trying to use Doppio for Peergos. It is a very cool project. In
the end we decided against it because it wasn't fast enough for our use case
yet, and it requires the page to download the whole JVM (at least the rt.jar -
the runtime) which is >60 MiB. We managed to get around this by manually
stripping out the parts of the JVM that we didn't need, which brought it down
to a few MiB.

I imagine that once they update it to Java 9 with the modular JDK (and
resultant splitting of rt.jar) this reduction will largely happen
automatically with it lazily downloading the parts that it needs.

------
mintplant
A similar project from Mozilla:
[https://github.com/mozilla/pluotsorbet](https://github.com/mozilla/pluotsorbet)

It was targeted toward running J2ME apps on FirefoxOS phones. With that
project dead it's no longer under active development.

------
crncosta
Atwood's Law:

"Any application that can be written in JavaScript, will eventually be written
in JavaScript."

~~~
mi100hael
Corollary:

"Any module written in JavaScript will eventually be ported to Go."

~~~
kodablah
Done [0] and done [1]. Though, the latter one at least, isn't really in a
production state because compiling the JVM stdlib takes hours in Go.

0 - [https://github.com/zxh0/jvm.go](https://github.com/zxh0/jvm.go)

1 - [https://github.com/cretz/goahead](https://github.com/cretz/goahead)

------
trynumber9
See also luje. "An experimental (read: toy) Java virtual machine written in
pure Lua."

[https://cowlark.com/luje/combined.html#index](https://cowlark.com/luje/combined.html#index)

------
flukus
Does it run java applets?

~~~
expertentipp
Java applets for JVM written in TypeScript transpiled into JavaScript will be
the next big thing. Freeze any browser, anywhere, instantly. Imagine the print
out of stack trace with error - so exciting.

------
mehrdada
(2014)

------
ndr
"Any application that can be written in JavaScript, will eventually be written
in JavaScript." \- Jeff Atwood

~~~
colordrops
So, every application will be written in JavaScript?

~~~
fredley
Every application that can

~~~
colordrops
Very few can't

------
peoplewindow
There is also TeaVM:

[http://teavm.org/](http://teavm.org/)

------
didibus
This is actually quite awesome.

------
z3t4
Would be cool if it could run GUI programs!

------
bwidlar
JVM written in Javascript, what could be wrong?

~~~
msgilligan
Don't worry, it has Nashorn ;)

~~~
Randgalt
Like Taco Town :D Run Javascript in the JVM in Javascript

------
the_duke
But... why??

Edit:

> This paper presents DOPPIO, a JavaScript-based runtime system that makes it
> possible to run unaltered applications written in generalpurpose languages
> directly inside the browser.

Someone should really have told them about webassembly...

~~~
lihaoyi
The first commit to Doppio was 13 Feb 2012

One year before asm.js appeared, in Mar 2013

Three years before WebAssembly appeared, in June 2015

Five years later, In 2017, WebAssembly still doesn't have a GC and cannot run
the Java/Scala/Groovy programs that Doppio was able to run in 2012

~~~
raddan
Doppio's lineage goes back even further than 2012. A "JVM in JS" was given in
Emery Berger's 691ST course in the fall of 2011. My notes show that I
submitted my "finished" JVM on October 26, 2011. I say "finished" because it
became obvious rather quickly that a lot of things would be difficult if not
impossible in JS (like threading and synchronization) and so we negotiated
with Emery to come up with a subset of Java that we could reasonably implement
for a class project. IIRC, there were 6-8 VMs written that semester.

Doppio proper (the repository you refer to) started during the spring meeting
of 691. Those guys went above and beyond the minimal spec we implemented, and
they tackled a lot of stuff that we thought was impossible. Thus the research
paper.

IIRC, we also had to write a decentralized chat program in JS that semester.
That was also "fun".

Yes, I created a HN account just to post this.

~~~
cscurmudgeon
Thank you. This is great work from both an engineering and scientific
perspective.

------
Koshkin
> _(Read the academic paper)_

I admire the effort, but: doesn't "academic" mean "scientific"? Can there
possibly be any "science" in having a well-known VM reimplemented in a well-
known programming language?

~~~
bdcravens
Yes, in the sense that it's called "computer science" with little scientific
method involved.

~~~
amelius
I got an error, so I falsified it according to the scientific method:

    
    
        Error extracting doppio_home.zip: Error: ENOENT: No such file or directory., '/persist/vendor/java_home/lib/images/cursors/cursors.properties'

~~~
emeryberger
File a bug report, please. Doppio is actively maintained, though our current
focus is on Browsix (which incorporates and extends some of Doppio's
functionality -- see browsix.org).

