On Wednesday, August 31, 2016 at 11:58:51 PM UTC+2, Ian Preston wrote: > > One idea, which would be awesome from a user perspective, is the following: > > Emulate CompletableFuture with native Promises. Then if the synchronous > cf.get() call is used, then translate that to await, and make the function > it is in async (in JS land). This would automatically change the signature > to a CompletableFuture, and then propagate this up to all callers. If it > makes it all the way to a function exposed with JsInterop, then that > function changes signature like the rest of them to return a promise. The > consumer of this function is obviously in JS and so can handle the promise > fine. This would equate to translating the synchronous java calls which > wait on a CompletableFuture (Promise) to return promises in JS. This > wouldn't require any changes to the Java code - it could continue in its > synchronous style, and not disrupt JVM based users of the same code. >
> Thoughts? > 'await' is not synchronous, which means things can happen while awaiting, which could mutate state you'd rely on being immutable because you 'synchronized' it (in other words: how would your proposal work with the 'synchronized' keyword? GWT currently simply ignores 'synchronized' because JS is single-threaded anyway; now what if you call CompletableFuture#get() within a 'synchronized' function, possibly several levels deep in the call-stack?). There are good reasons why only async functions can call async functions, and only async functions can use the await keyword: explicit vs. implicit. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
