The authors of this project can preload the JDK with a progress bar and stash it into IndexedDB, since Doppio's file system, BrowserFS, supports arbitrary backends .
If they didn't.... then it might be sufficient, but I am not sure how well the browser cache handles large files! How long until it evicts them? Is there an upper bound on the size of cached items? etc.
There's a `browser.cache.disk.max_entry_size` setting that defaults to 51200 (50MiB), however the code also has an explicit override that no item larger than 1/8 of the total cache size (as dictated by `browser.cache.disk.capacity`, default 350MiB) is ever cached, hence the 43.75MiB limit.
All these settings can be changed, obviously, but I suspect few people ever touch them.
I assume other desktop browsers have similar default limits, while mobile browsers probably have a much lower threshold.
If you find any issues with Doppio or have any requests, feel free to open up an issue on our GitHub issue tracker.
Numeric support. Direct support for 64-bit integers would enable
languages to efficiently represent a broader range of numeric types
in the browser. The DOPPIOJVM uses a comprehensive software
implementation of 64-bit integers to bring the long data type into
the browser, but it is extremely slow when compared to normal
how far is this from being solved?
There is a proposal for value types  that Niko Matsakis  and Brendan Eich  talked about a couple of years back and could be used to implement 64-bit numbers in JS, but I'm still waiting for an implementation or a more complete proposal. Looks like it might be dead in the water, as the proposal hasn't been edited in quite some time, but I do not have my finger on the pulse of browser standards so I could be wrong.
(I'm the primary author of Doppio.)
If that sounds like fun, I take pull requests . :)
I always imagined something like this should use the <object src="app.jar" /> tag. If you consider that someone could build a browser again with java in it, (like I have) then it would be good to design a polyfill such that, it allows for a native version to exist (and then doesn't run)
Also using the same mimetype for jars, classes and source files seems non optimal.
It would be really good if gwt,doppio,teavm all agreed on a single api facade for targeting the browser API. I think that would really put some steam behind the underlying idea here.
This is actually one of the larger differences we describe in the academic paper that sets Doppio apart from those projects and Emscripten .
 Start of the conversation: https://groups.google.com/d/msg/plasma-umass-gsoc/uuZk09CGIM...
 PLDI 2014 paper (Sorry, I know I'm linking this a lot in the comments thread, but I promise it's a fun read!): https://plasma-umass.github.io/doppio-demo/paper.pdf
'Async demo that shows how TeaVM can translate multithreaded applications with synchronization primitives.'
Also see this effort trying to unify the APIs: http://dukescript.com/
I haven't checked in with this project since we last talked a few years ago, so it's nice to see notable progress! Thanks for the pointer.
The WebAssembly standard is constantly evolving, and now contains some ambiguous statements regarding the ability to take advantage of the browser's GC . Considering WebAssembly's current focus on C/C++ code, I do not believe this will come to fruition anytime soon. If it does, I do not see how it would noticeably improve Doppio's current performance, which is bottlenecked primarily by its interpreter. A contributor is working on a JIT right now to make execution faster .
Hope that clarifies!
Also if someone says this is useless an interesting use case could be e.g. a hybrid navigation application
https://karussell.wordpress.com/2014/05/04/graphhopper-in-th... or portable native apps using a webview
BTW: I got lots of errors in the Firefox console saying 'Error: Assertion failed: A non-running thread has an expired quantum' although the example works (should have a progress bar :))
I suspect the assertion failure is caused by some of their modifications to Doppio's start up code to pause and extend the main thread's runtime.
(I contribute to both Javapoly and Doppio)
Javapoly tries to make Doppio easier to use (in my subjective opinion):
* easier loading of jars, classes and Java source code
* a promise based async interface to Java methods
* automatic marshaling of primitive values between JS and Java lands
* a proxy based interface into the Java namespace.
As a very crude analogy: shells and editors make it easy to use the filesystem. But we can't contribute the shell / editor to the filesystem! They sit in different layers of the stack.
FIXED - forget this video, watch John deliver it at Microsoft Research! http://research.microsoft.com/apps/video/default.aspx?id=238...
I'm on a pretty anemic computer, but there's got to be a way to keep my browser responsive while it loads in everything it needs.
Note: jvilk explains the perfectly valid reason for this library in another comment below.
It's still a very neat hack, though!
having text/java as MIME type - instead of at least looking up the correct one in Wikipedia makes this implementation look quite uggly on the first sight.
Also I cannot imagine a single valid usecase for this.
(Joking; both of those projects are pretty great, and have different goals from Doppio.)
(Also, Scala in Doppio is... uh... quite slow. As you may imagine, if you are familiar with Scala's compilation process.)
Also, more languages than just Java run on the JVM; Doppio can run Scala, Clojure, and other JVM languages.
But it seems to download crazy Java stuff and I get "threadpool.ts:83 Uncaught TypeError: Cannot read property 'run' of undefined" with Chrome 50.
They don't mention it anywhere, but you can find it in the package.json file in their git repo.
Doppio itself is under the MIT license.
A recent contributor is starting to add a JIT to Doppio, which is a step in the right direction .
 Our academic paper from PLDI 2014 has more details, although the project has evolved since then (it's now JDK8 compatible, for example): https://plasma-umass.github.io/doppio-demo/paper.pdf
The nitty gritty details are in the PLDI 2014 paper . Some details have slightly changed, though (e.g. DoppioJVM supports JDK8 now).
You can actually polyfill WeakMap and WeakSet. You can't do the same for weak references.
Our approach was to leverage the existing GC and language features that browsers already have.
Then I realised the answer was probably "because they could".
Someone will write a C compiler in Java and stuff it in the browser next...
 Doppio: Breaking the Browser Language Barrier paper from PLDI 2014: https://plasma-umass.github.io/doppio-demo/paper.pdf
Have you encountered any practical use cases?
Also, note that Doppio is an interpreter, so there is significant interpreter overhead. Using a JIT compilation approach would improve performance, and a contributor is currently working on a basic implementation. I honestly believe that it could become significantly faster with additional work, but as a single person with other projects, I lack the resources to do this work myself.