GWT 2.9.0 support for SmartGWT and migration to JsInterop

[nwilton]

With the announcement of GWT 2.9.0 (https://groups.google.com/d/msg/goog...I/-lxHncJnAAAJ), does SmartGWT plan to provide compatibility with this version? and plan to provide in-step compatibility with the new release cycle?

In addition, JSNI is now deprecated and will be removed with GWT 3.0. I understand that JsInterop is the replacement to JSNI, and offers additional capabilities above JSNI. What is the migration path away from JSNI and towards JsInterop for SmartGWT? I don't want to invest in SmartGWT knowing it will not be compatible with the long awaited GWT3 (which seems closer now with this announcement).

[Isomorphic]

We don't know of any incompatibilities with GWT 2.9. We haven't had incompatibility with previous releases because we don't use GWT for anything except Java > JS translation. Our widgets, data binding, class system etc is all separate.

For the same reason, JSInterop will not change any of SmartGWT's APIs.

If there is some functional improvement that is possible in the framework that you believe GWT's new features enable, please let us know.

[nwilton]

My understanding is that SmartGWT extensively uses JSNI for the Java > JS translations, which is now deprecated. Is there plans to update this to JsInterop?

[Isomorphic]

At the moment, JSInterop does not appear to be capable of supporting the SmartGWT API - certainly not an API compatible with the existing SmartGWT API.

We certainly would not change to JSInterop, with zero functional advantage, and encourage all of our customers to port their code to a new API, again with no functional advantage.

We will be coordinating with the GWT team to make JSInterop a viable replacement for JSNI. Then, it will be easy and quick to port, since most of the JSNI in SmartGWT is actually generated code.

[nwilton]

encourage all of our customers to port their code to a new API, again with no functional advantage.

The advantage is support for newer Java releases for SmartGWT projects. This is the #1 issue with SmartGWT/GWT 2.8.2 today, it is stuck with Java 8.

We will be coordinating with the GWT team to make JSInterop a viable replacement for JSNI. Then, it will be easy and quick to port, since most of the JSNI in SmartGWT is actually generated code.

Yes, please do this. It's important for SmartGWT to remain current with all future GWT releases.

[Isomorphic]

Why do you believe SmartGWT is stuck with Java 8? Did you have trouble using GWT 2.9? You don't seem to have reported any issues.

[nwilton]

GWT 2.8.2 was stuck on Java 8, GWT 2.9 is expected to work with Java 11. GWT 2.9 isn’t on Maven yet, but I’ll try when it is.

What I’m ideally looking for is a commitment to continue to support SmartGWT with GWT3 when it arrives.

Thanks

[Isomorphic]

We will continue to support GWT as it evolves unless they deprecate JSNI with no viable replacement. That would be suicidal for the GWT project, so we don't think they'll do that :)

[nwilton]

We will continue to support GWT as it evolves unless they deprecate JSNI with no viable replacement. That would be suicidal for the GWT project, so we don't think they'll do that :)

Thanks.

GWT3 is mostly about replacing the compilier with J2CL. JsInterop is part of Google's J2CL project, not GWT, but it's still worthwhile asking the GWT team about SmartGWT compatibility if there are some questions there. https://github.com/google/j2cl

There is probably an opportunity for Isomorphic to support Java code via J2CL given that is the exact direction GWT is going. Maybe that is a better wishlist post than the one I originally made. Can support for SmartClient be extended to J2CL as an alternative to GWT ?

[Isomorphic]

Here again we would ask: is there a functional advantage, if so, what is it?

[nwilton]

It's not about functionality, it's about the writing on the wall for the GWT2 Java-to-JS complier and projects needing to migrate off it for currency reasons (before today it was 3 years since the last update).

The GWT project themselves are building a bridge to J2CL. GWT3 will be about libraries and tooling (not JS to Java compilation), which SmartClient already provides. So SmartClient moving to provide official J2CL support via a wrapper makes sense.

[Isomorphic]

Sorry, we're not really following you here. You seemed to be suggesting that we directly support J2CL in addition to GWT3.. why? Why wouldn't we just continue to support GWT as it transitions to J2CL?

Are you suggesting we just abandon GWT since GWT is moving to J2CL anyway? Some people do use some GWT APIs alongside SmartGWT, we wouldn't want to abandon them.

And again is there some functional advantage? Currency per se is not a functional advantage.. are you imagining that debugging via J2CL might be a better process than with GWT, or get there sooner, something like that?

[nwilton]

Sorry, we're not really following you here. You seemed to be suggesting that we directly support J2CL in addition to GWT3.. why? Why wouldn't we just continue to support GWT as it transitions to J2CL?

SmartGWT uses the GWT SDK complier to provide a wrapper to the SmartClient Javascript API via Java code. i.e. Write client-side code in Java for SmartClient.
GWT3 will be a set of libraries and enterprise tooling (basically the same as what SmartClient provides)

Are you suggesting we just abandon GWT since GWT is moving to J2CL anyway? Some people do use some GWT APIs alongside SmartGWT, we wouldn't want to abandon them.

There is a transition happening, that we have all hitched a ride on. The goal of GWT3 is cross-compatibility with both the GWT2 complier and J2CL, my 'wishlist' suggestion is that SmartGWT has the same stated goal.

And again is there some functional advantage? Currency per se is not a functional advantage.. are you imagining that debugging via J2CL might be a better process than with GWT, or get there sooner, something like that?

About 20% of my project is client-side code on SmartGWT. All my core application is server side with the remaining 80% of the Java code. So I care more that my server side code isn't held back by the end-of-life decisions about GWT2 that SmartGWT might hitch itself to. There are clear functionality disadvantages by not upgrading Java. My server code has already been held back on Java 8 for 3 years, thank god that ends today. e.g. I have had to avoid Java libraries versions that rely on Java Modules that were introduced in Java 9.

[Isomorphic]

You didn't directly answer, but, it seems like what you're saying is: you think that J2CL might support new Java versions faster than GWT, so, if SmartGWT was usable with just J2CL, then you wouldn't have to wait for the GWT project to support new Java versions.

Right?

If that's *not* the functional advantage of direct J2CL support, then please explain what the advantage is.

[nwilton]

Yes, J2CL has Google's backing and is an active, regularly maintained project. And that means better Java support, and fixes for other issues.

Supporting J2CL alongside GWT is a possible goal. That's my wishlist item. You don't have to do anything of course, but there are significant changes happening in this space and I have a vested interest in seeing SmartGWT embrace those.