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 google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/6a21e419-db7f-4cc0-8efc-52e0aed24237n%40googlegroups.com.
