2 years later was: Converting JS to async JS

[jarosla...@gmail.com]

Hi.
I've noticed your reference to bck2brwsr's limitations at [hackernews](https://news.ycombinator.com/item?id=11655582) and I'd like to point out that I never received a reply to my "asych" JavaScript proposal.

The narrativejs moved meanwhile to
https://sourceforge.net/projects/narrativejs/
but the idea is the same. All @JavaScriptBody snippets calling back to Java would be made asynchronous in your VM.

I asked for a help to identify the place where to handle the @JavaScriptBody in your code base and offered a help to handle the rest. Rather than shouting to the world that bck2brwsr maintainer gave up due to inherent limitations, let's say that I slowed down due to lack of co-operation.

With a bit of help I can still take a look.
-jt



Dne úterý 25. března 2014 11:14:21 UTC+1 Jaroslav Tulach napsal(a):
> Hello again.
>
>
> > I'll try to propose something...
>
>
>
> OK, so the clueless solution, e.g.:
>
>
>
> 2014-03-24 20:58 GMT+01:00 John Vilk <jv...@cs.umass.edu>:
>
>
> Your previous email was sent to me only. I've pasted it below.
>
>
> As you realized, this is not possible:
>
>
>
>
>
>
> future = makeAsyncCall();
>
> while (!future.isFinished()) {
>   makeAnotherStepInTheVM();
>
>
>
> }
>
>
> ...because browser callbacks, such as asynchronous XmlHttpRequests, will not fire until your program stops running and returns to the browser event loop.
>
>
>
> will not work. That however does not mean Doppio cannot support @JavaScriptBody. All that is needed is to convert JavaScript to its asynchronous form. E.g. to make sure 
>
>
>
> @JavaScriptBody(args = {"r"}, javacall = true, body = "\n" +
> " r.@java.lang.Runnable::run()();\n" +
> " r.@java.lang.Runnable::run()();\n" +
> " ")
> public static native void twoCalls(Runnable r);
>  
> is converted to something like:
>
>
> doppioCall(r, 'java.lang.Runnable', 'run', []).then(function() {
>
>   doppioCall(r, 'java.lang.Runnable', 'run', []);
> });
>
>
> Such conversion requires a bit of parsing of the JavaScript code, but looks like, somebody has already done the work:
>
> http://www.neilmix.com/narrativejs/
>
>
>
> I agree this is more work than I originally expected, but if there is will, it is still reachable goal.
>
>
>
> If you handle the VM<->JS binding (e.g. recognize JavaScriptBody, invoke JS and come up with some form of doppioCall/then API), I can handle the conversion of synchronous JS to asynchronous one.
>
>
>
> -jt
>
>
>
>
>
>
> Jaroslav's email:
>
>
>
>
>
> Hello John,
>
>
> in addition to previous motivating email, I have to admit I see the problem now:
>
>
>
> 2014-03-22 1:05 GMT+01:00 John Vilk <jv...@cs.umass.edu>:
>
>
>
>
> In Doppio, all JVM method calls are necessarily asynchronous from the JavaScript point of view. We do this because:
>
>
>
> A long running method will freeze the browser, so we need to yield periodically. This is the common case in existing Java code; it's not written in an event-driven style for the web.
>
>
> - this is not a problem (especially if we add wait4java = false).
>
>
> This gives us the freedom to perform a context switch between threads.
> - this is not problem either. 
>
>
> Many of our Java native methods hook up to asynchronous browser functionality (for example, file system operations), which requires JavaScript execution to return to the browser event queue to wait for the callback to fire.
>
>
> However this one is nasty. One cannot each the browser callback with artificial "while (!isFinished())" loop. 
>
>
> Classloading in Doppio is asynchronous, as it needs to pull in class information from our file system. If a method called from JS references a class that hasn't been loaded into the classloader yet, Game Over!
>
>
> This one is not nice either.
>
>
>
> Unless you change your JVM->JS interoperability story regarding method calls to be asynchronous, this sort of compatibility just fundamentally isn't going to work.
>
>
>
>
> The point of JavaScriptBody is to provide 100% interop with GWT. The migration needs to be smooth.
>
>
>
>
>
>
> We explain why we do this extensively in our paper:
> http://jvilk.github.io/doppio-demo/paper.pdf
>
>
>
>
> That is the same paper as you sent me last time. I have memorized it! 
>
>
>
>
> In particular, Section 3 explains the strangeness of the browser compared to the native environment, and Section 4 explains the Doppio approach to overcoming it.
>
>
> I have not noticed the problem of a browser callback (bad memory, I guess).
>
>
>  
> Sorry to be the bearer of bad news.
>
>
>
>
> That is OK. I was expecting this answer and had the "while (!isFinished())" answer prepared. Too bad it does not work for browser callbacks. But the seek is not over...
>
>
>
>
> I'll try to propose something...
>
>
>
>
>
>
> On Mon, Mar 24, 2014 at 3:21 PM, Jaroslav Tulach <jarosla...@gmail.com> wrote:
>
>
>
> Hello John.
> Here is first part of my email, the optimistic one. Others will follow...
>
>
>
>
>
>
> 2014-03-22 1:05 GMT+01:00 John Vilk <jv...@cs.umass.edu>:
>
>
>
> Hey Jaroslav,
>
>
> Thanks for reaching out again.
>
>
>
>
> > Alexey's VM also recognizes @JavaScriptBody annotation as such Bck2Brwsr VM and TeaVM can run the same libraries and applications.
>
>
>
>
>
>
>
> Congratulations! I'm happy that you two were able to discuss this and get it working. :)
>
>
>
>
>
>
> You would not believe how hard it was! Initially Alexey argued that @JavaScriptBody is too general, that it does not fit TeaVM's visiion and that it would be better to use completely different approach (I am sure you can envision the complains). Alexey was of course right - @JavaScriptBody does not optimize for the strongest points of TeaVM. I almost gave up, but then Alexey finished his implemention and I believe he need not be sorry: Now any DukeScript library works well on top of his VM (without even knowing about TeaVM). 
>
>
>
>
>
>
> I am convinced there is a value in having shared "common ground", even if it does not use the best of our VMs.
>
>
> Btw. the @JavaScriptBody does not use the best of Bck2Brwsr VM either. It is a bytecode formalization of GWT's JSNI and its biggest value is that any library written against GWT (and believe me there are some) can be automatically converted to @JavaScriptBody and executed on our VMs.
>
>
>
>
>
>
>
>
> > I would still be interested in Doppio recognizing the annotation as well.
>
>
>
>
>
>
>
> Unfortunately, I don't think this will be feasible. I looked at some sample code for @JavaScriptBody, and it looks like you can call Java methods from the JavaScript. For example, see addColorStopImpl in this following link:
>
>
>
>
>
>
>
> http://jayskills.com/blog/2013/01/22/canvas-for-bck2brwsr/
>
>
> In Doppio, all JVM method calls are necessarily asynchronous from the JavaScript point of view.
>
>
>
>
>
>
> I knew you would have to say this! This is the biggest added value of Doppio compared to Bck2Brwsr VM and TeaVM.
>
>
> I understand the value of asynchronousness and actually the only addition to @JavaScriptBody (in version 0.7.6) was a new attribute "wait4js=false" - which was necessary to make the Android port effective. If you insist, we can certainly let library writers specify "wait4java=false" and be very effective on Doppio.
>
>
>
>
>
>
> On the other hand, explicit asynchronousness is hard and thinking about it is usually the last thing to do (I tried almost everything to avoid the addition of wait4js). So I am sure library writers will start with synchronous calls - and they need to behave the same on all platforms.
>
>
>
>
>
>
> That is why Doppio would also have to support synchronous mode. However I know exactly how hard that is:
>
>
> future = makeAsyncCall();
> while (!future.isFinished()) {
>
>
>
>
>   makeAnotherStepInTheVM();
> }
>
>
> While I fully understand the benefits of having Doppio asynchronous mode, I also know that there are no technical reasons to not support synchronous one. Sure, such support may not be nice, in fact it may even be ugly, may go against the beauty of original design, but it would give us ability to run DukeScript and (after conversion) any GWT libraries.
>
>
>
>
>
>
>
>
>
>
> We do this because:
>
> A long running method will freeze the browser, so we need to yield periodically. This is the common case in existing Java code; it's not written in an event-driven style for the web.
>
>
>
>
> A long running method would of course freeze the browser. A pragmatic solution is to write shorter methods, or use wait4java = true.
>
>
>
>
> To be continued...
>
>
>
> -jt

[John Vilk]

Ack, I hope my comments were not interpreted as a slight! My mental summary of our conversation was that "Doppio's asynchronous/yielding strategy is incompatible with the bck2brwsr API", which is what I wrote on HN. I had not noticed or remembered that you left the ball in my court. Perhaps I should have examined our conversations more closely before commenting!

A commenter on HN also proved me wrong about TeaVM; I had not realized they added multithreading support. So I guess I struck out twice on that comment.

I will try to take a look at the current proposal later on in the week.

Sorry for the misunderstanding.

John

--
You received this message because you are subscribed to the Google Groups "PLASMA at UMass: Google Summer of Code" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plasma-umass-g...@googlegroups.com.
To post to this group, send email to plasma-u...@googlegroups.com.
Visit this group at https://groups.google.com/group/plasma-umass-gsoc.
To view this discussion on the web visit https://groups.google.com/d/msgid/plasma-umass-gsoc/8de3a954-3274-45c0-bf28-b9a12c39f955%40googlegroups.com.

[John Vilk]

Also, I realized I also mentioned something in a comment about an async API proposal that "you rejected". When I said that, I was remembering this comment:

So, from your documentation, if we adopted your name mangling, this bck2browser code:
var r = s.substring__Ljava_lang_String_2II(0, 5);
... would become the following Doppio code:
s.substring__Ljava_lang_String_2II(0, 5, function(r) {
// Rest of function logic
});
This is the price we have to pay for multithreading support and for emulating synchronous Java APIs using asynchronous JavaScript APIs.

...which is a far cry from a proposal. 

I roughly remembered you rejecting the asynchronous change, and tried to find a way to make Doppio's JVM calls synchronous. That's reflected in your quoted email exchange above.

What I did not remember is your reply with the link to narrativejs.

 

Again, truly sorry for the misunderstanding.

John