Thanks both, for the pointers! On Tuesday, May 20, 2025 at 7:05:29 PM UTC+2 Colin Alworth wrote:
> The CF implementation for GWT was at > https://github.com/OneGeek/GWT-CompletableFuture. > > The Promise.java isn't going to be quite the same in Java and JS if you > decide to go that way, but maybe it won't matter. Downstream then's and > such are evaluated as microtasks after the current task/microtask > completes, which keeps both keeps the stack from growing out of control and > also lets other pending work complete before going back and picking up > other work to resume. If you support threading when executing in a JVM (but > not in the browser), you probably already have some other code to handle > deferring work like this, and the required locks or other controls to keep > your data safe from races - but those differences are usually meaningful, > so I would hesitate to _generally_ conflate a browser Promise with JVM > CompletableFuture with its assumptions about ForkJoinPool, etc. > > On Tuesday, May 20, 2025 at 10:46:53 AM UTC-5 Jens wrote: > >> GWT itself uses an inner static class to define the native browser API >> via @JsType and then use that to implement the super source version. As an >> example you can look at Date at the very bottom: >> https://github.com/gwtproject/gwt/blob/main/user/super/com/google/gwt/emul/java/util/Date.java >> >> I wouldn't write JSNI anymore. JSNI is hidden code in a comment which >> makes reference search etc annoying if the IDE does not have good JSNI >> support. >> >> Using elemental2 Promise directly on the server isn't possible without >> replacing it with a JRE variant. A more natural approach would be using >> Java's CompletableFuture / CompletionStage and then emulating this API >> using Promises on the client. I can remember someone in this group did it >> that way and published the code on github somewhere. If you search the >> group you probably will find it to take a look. >> >> -- J. >> >> Alexander Bertram schrieb am Dienstag, 20. Mai 2025 um 08:44:24 UTC+2: >> >>> Hi all, >>> >>> So long long ago, I wrote a Promise class for our GWT project to make >>> easier to write complex async code that ran in the browser but could also >>> be run in Junit tests running in the plain JRE, and sometimes on the server >>> in cases where we could assume the Promise would complete synchronously. >>> >>> Fast forward 10+ years, and the Promise has long been standardized and >>> baked into browsers themselves, WITH great support in DevTools for >>> following the path of a Promise across resolutions. >>> >>> I'm refactoring this class to use the browser's native Promise >>> implementation. Normally the way I would do this is: >>> 1. Align the Java implementation class to the Browser's Promise API >>> 2. Add a supersource implementation that uses JSNI to invoke the >>> browser's API when compiling. >>> >>> BUT - is this still the "best" way to do this in 2025, with @JsTypes? >>> AND - there is already a Promise class in the elemental library that we >>> use extensively, but it's a "native" class, so we can't use it in the JRE. >>> Can I provide a JRE-safe implementation of elemental2.promise.Promise >>> without monkey-patching elemental2-promise ? >>> >>> Has anyone else implemented something similar? >>> >>> Best, >>> Alex >>> >>> >>> -- 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 view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/6a21e419-db7f-4cc0-8efc-52e0aed24237n%40googlegroups.com.
