There are sort of two categories of these - the ones on your JSOs, i.e. already native types, so you just want to describe the real JS API, except in terms that let you use it in Java, and cases where you need a util method to do something in JS that seemed difficult to do in Java. For the first, you mostly just add a @JsType(...) annotation, remove the JSNI body and make sure the method signature matches what will make sense in JS.
Here's an example of a class in com.google.gwt that has been ported, maintaining as much of its api as possible, while also now being compatible with J2CL:
Before: https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/typedarrays/client/DataViewNative.java
After: https://github.com/Vertispan/gwt-typedarrays/blob/master/src/main/java/org/gwtproject/typedarrays/client/DataViewNative.java
For the second case, with lambdas in Java 8 and jsinterop annotations, this is much simpler than it used to be. My standard approach is to remove the "native" keyword and "/*-", "-*/;" tokens, and then look for syntax errors. Most of my projects still assume Java 8 as a baseline, so "var" is a problem, but if you are using recent Java you can leave that in and just go after the other oddities.
For the most part, you can use Elemental2 types to get a pretty close-to-JS experience. Sometimes you'll need to "cheat" a bit with a Js.cast() or Js.uncheckedCast() to get to the matching type.
Here's an example where JSNI was probably not needed to begin with (and with the bug left intact for complete backward compatibility):
Before: https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/typedarrays/client/JsUtils.java#L47-L53
After: https://github.com/Vertispan/gwt-typedarrays/blob/master/src/main/java/org/gwtproject/typedarrays/client/JsUtils.java#L58-L64
Here's a more complex example - note that to achieve this, the odd annoying cast is required, as well as a new SAM interface, DOMImplStandard.Fn, which just has a onEvent(Event) method, and is marked as @JsFunction (https://github.com/treblereel/gwt-widgets/blob/master/gwt-widgets/src/main/java/org/gwtproject/user/client/impl/DOMImplStandard.java#L435-L440 for the source)
Before: https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplStandard.java#L315-L353
After: https://github.com/treblereel/gwt-widgets/blob/master/gwt-widgets/src/main/java/org/gwtproject/user/client/ui/impl/RichTextAreaImplStandard.java#L324-L365
This could probably be made slightly more pretty, but the goal while porting this was to just get it done quickly (and as a result of these efforts, nearly all of gwt-user.jar in some way or another works in J2CL today).
Generally, your JSNI methods should be shorter than this, so it becomes a matter of knowing which tools are out there, and which parts of Java+JsInterop map nicely to which parts of JS. When you find something missing, 99% of the time it can be found in jsinterop-base - the Js class there provides a bit of extra glue for things that can't be expressed easily in both GWT2 and J2CL.
The really ugly way that Thomas was alluding to is moving JS to an external JS file, but this is not the path of least resistance, it may be brittle (unless you take great care to use JsInterop annotations to avoid renames, changes in the compiler could break how you reference Java), and it will not be GWT2 compatible any longer. Using JsInterop as the examples above show should be simpler, more correct, and let you finish most of your migration before you even glance at J2CL.
On Friday, May 22, 2020 at 7:46:58 PM UTC-5, GWT dev wrote:
Thanks. I see various overviews for jsinterop, including the official one from GWT. However, what about a migration guide? I.e., given a JSNI method what would the path-of-least-resistance translation look like?I'm guessing you'd have to move the JSNI code itself into a JS file, declare it with types from the Java side, and then use jsinterop again (by adding declarations as needed) to support that now pure JS code calling back into GWT Java (as JSNI can do). Something like that?
On Friday, May 22, 2020 at 5:18:22 PM UTC-5, Thomas Broyer wrote:
On Friday, May 22, 2020 at 11:35:29 PM UTC+2, GWT dev wrote:Can you provide some clarification for us?
- Is it definite that JSNI will not be supported in the first GWT 3.x release?
Yes.There is an alternate way to do the same with J2Cl when it's absolutely required, but it's not JSNI, and most of the time you shouldn't need it.
- Will JSNI continue to be supported in future GWT 2.9.x releases if they are made?
Yes, because there's no reason to remove it.
- As for GWT 2.9.0, we don't see any deprecation warnings during compilation for JSNI, but you're saying JSNI is actually deprecated as of the 2.9.0 release, or is that a forward-looking statement targeting potential future 2.9.x releases?
It's "deprecated" in the sense that it's still supported but you're encouraged to not write new JSNI methods anymore; use JsInterop instead, with the help of jsinterop-base and Elemental 2.On Wednesday, May 13, 2020 at 10:40:25 PM UTC-5, Colin Alworth wrote:Today we are pleased to announce the next release of GWT, version 2.9.0. Some highlights of this release:* GWT supports Java 9, 10, 11 language features.* The elemental2 1.0.0 release is supported, along with jsinterop-annotations 2.0.0 (except @JsAsync, which requires dropping support for older browsers, and @JsEnum, which assumes closure-compiler semantics, so isn't appropriate for GWT2), bringing GWT2 in line with J2CL. Since this is now an official stable release of elemental2, the JSNI-based elemental that is included with GWT is deprecated, and will be removed in a future release.* The release was tested on a variety of operating systems, on Java 8, 11, and 14. Java 7 is no longer officially supported, and future builds will be compiled for Java 8 as the minimum required version.Starting shortly after this release, we're going to be changing the release process slightly - there will be more frequent dated releases (something like 2.9-20200701) that occur every few months, and minor/bug fix releases that happen intermittently to signify that a more lengthy manual testing and acceptance process has taken place. The idea is that with more frequent releases, changes will make their way faster to the developers that want them, while for others, more heavily tested releases for maintenance-mode projects will still be available.We'll also be talking soon on the contributors list about the upcoming releases of individual projects that represent the various modules found in gwt-user.jar, updated and tested for use in either GWT2 or J2CL.We're experiencing some issues in updating the gwtproject.org website, but to get this release out while that is managed, find the zip download and the release notes below. Maven/Gradle/Ivy users, just update the GWT SDK versions to 2.9.0 - the various plugins will be updated as needed in the coming days.GWT SDK zip download: https://storage.googleapis.com/gwt-releases/gwt-2.9.0.zip ----Release Notes for 2.9.0:
Highlights
- Able to compile projects with jsinterop-base 1.0.0, elemental2 1.0.0, and jsinterop-annotations 2.0.0. With the exception of @JsAsync and @JsEnum, this brings GWT2 to be compatible across these tools with J2CL.
- Added support for Java language levels 9, 10, and 11.
- Officially, support is dropped for running the GWT compiler or server-side tooling on Java 7. The GWT distribution is still compiled to run on Java 7 for this release, but no guarantees are made about whether or not this will work. Future versions will compile bytecode for Java 8+. The release was tested and found to work cross platform when run with Java 8, 11, and 14.
Deprecations
- Elemental has been officially deprecated - it is still included in this release, but may not appear in future releases. Instead, we encourage the use of the Elemental2 libraries, which are compatible with both GWT2 and J2CL.
- Removed NoSuchMethodException emulation.
Bug fixes
- Fixes Arrays.binarySearch semantics for float[] and double[]
- Adds Support multi-line messages in errors/exceptions
- Adds shutdown hook in DiskCache to clean up temp files
- Cache Gecko version to lower CPU usage on FireFox
- Do not assume that "this" is always non null.
- Updates globals for Firefox version 60.0.2, Chrome 66.0.3359.45
- Fixes String.regionMatches.
- Native JsMethods allowed to coexist with implementations with the same name.
- Make sure lambdas box, unbox and insert erasure casts when necessary.
- Negative zero treated properly in Double/Float.compare()
MiscellaneousFor more detail, see the commit log.
- Updates CLDR to version 34.
- Arrays now implement Cloneable
- Link backing errors together with a cause attribute, start tracking suppressed errors in addition to the cause in underlying error object.
- Add AtomicReference to gwt/emul.
- Propagate script nonces via ScriptInjector
- Add partial emulation for ExecutorService and ScheduledExecutorService
- Emulate java.util.concurrent.Flow
- Emulate javax.annotation{,.processing}
.Generated - Make sure "goog.global" is $wnd if not defined.
- Add when-linker-added element definition
- Add Reader and StringReader emulation.
- Remove GWT version check.
- Do not show "unusable-by-js" warning for synthetic methods.
- Update unmodifiableList to throw on Java8 methods.
- Disable DataflowOptimizer by default and emit a warning when used
----Finally, if you haven't already done so, please join the very active GWT discussions happening at https://gitter.im/gwtproject/gwt !
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/210e4188-9d6a-4394-b4a8-fe2d290ebf10%40googlegroups.com.
No comments:
Post a Comment