Hacker News Reader

Comment by grizzles | Hacker News Reader

I have an experimental version of chromium running with the JVM somewhere on my HD. It's pretty easy to do with CEF/JCEF.

Two thoughts:

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.

View on HN

> It would be really good if gwt,doppio,teavm all agreed on a single api facade for targeting the browser API.

Unfortunately, that is impossible due to differing requirements; I've actually talked with the teavm and bck2brwsr folks [0]. Doppio requires asynchronous function calls to support preemptive multithreading. TeaVM, GWT, and bck2brwsr all map Java methods directly to synchronous JavaScript methods, preventing them from supporting multithreading.

This is actually one of the larger differences we describe in the academic paper that sets Doppio apart from those projects and Emscripten [1].

[0] Start of the conversation: https://groups.google.com/d/msg/plasma-umass-gsoc/uuZk09CGIM...

[1] 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

To my knowledge TeaVM supports multi threading. See the async demo: http://teavm.org/

'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/

Interesting! A cursory glance at the source code looks like they are doing some form of stack splitting at synchronization points, denoted by method annotations. Note that they reimplement the class library and eschew compatibility with traditional Java programs, so I'm not completely sure how general purpose their threads are. I tried finding some writeup about them, but I suspect the code is the documentation. :)

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.

What are your thoughts on WebAssembly? Do you see Doppio suppporting it as a target in the future?

One of Doppio's explicit goals was to leverage existing resources in the browser to bring conventional programming languages to the web on top of JavaScript. Using WebAssembly would prevent Doppio from using the browser's garbage collector; we would have to write our own. It would also prevent Doppio from mapping JVM objects onto JavaScript objects.

The WebAssembly standard is constantly evolving, and now contains some ambiguous statements regarding the ability to take advantage of the browser's GC [0]. 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 [1].

Hope that clarifies!

[0] https://github.com/WebAssembly/design/blob/master/GC.md

[1] https://github.com/plasma-umass/doppio/pull/443

It could be an async api facade. It would just happen to be mostly synchronous in those other cases.

Absolutely true. I believe I proposed that in our correspondence, but it was a dealbreaker for bck2brwsr and TeaV M, which is understandable.

Reply on news.ycombinator.com