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.
Announcement
Collapse
No announcement yet.
X
-
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?
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.
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?Last edited by nwilton; 14 May 2020, 16:28.
Leave a comment:
-
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?
Leave a comment:
-
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.
Leave a comment:
-
Here again we would ask: is there a functional advantage, if so, what is it?
Leave a comment:
-
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 :)
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 ?
Leave a comment:
-
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 :)
Leave a comment:
-
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
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
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?
Leave a comment:
-
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.
Leave a comment:
-
GWT 2.9.0 support for SmartGWT and migration to JsInterop
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).Tags: None
Leave a comment: