Interesting question, Thomas. I believe it should still work. Consider the 
following: 

1. A 'thread' comes into a method and obtains a lock on A.
2. whilst holding the lock, it makes an async call to 
CompletableFuture.get()
3. Somewhere down the call stack some state which is guarded by the lock on 
A is modified
On the JVM, either that lock is not re-entrant, in which case it is a 
deadlock, or it is re-entrant and modifying the state is fine. We only have 
one thread in JS so it is fine. 

Correct me if I'm wrong, but I believe this means that GWT could continue 
to ignore synchronization, and get the same results assuming non 
deadlocking programs, which can't be translated without a full emulator 
like doppio anyway. 


On Thursday, 1 September 2016 10:22:08 UTC+1, Thomas Broyer wrote:
>
>
>
> 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.

Reply via email to