2.9 progress

[stuckagain]

Now that j2cl is open sourced I see a lot of enthousiasm for working with it, which is great.

But how does that impact 2.9 release with Java 11 support ? I don’t see a lot moving here: https://github.com/gwtproject/gwt/milestone/19

We are going to release a product that is currently depending on the snapshot head release of GWT, witch by company policy is not allowed.

Is there any way I could help in getting a 2.9 release ready ? what is holding it back at this moment ? I don’t see any mention of Java 11 in the milestone list of issues. So I guess all the rest are bugs that existed before ... so why block a release for those or where those regressions ?

Sorry to keep on asking about 2.9 but that release is in my opinion more important for existing applications for the short term than a 3.x release.

[Jens]

I think the JDT version GWT currently uses does not officially support Java 11. However Java 11 has no notable syntax changes except the var keyword for lambda parameters. So it might work, but maybe it doesn't. Have you tried running GWT with Java 11 and using that new syntax?

Also no Java API emulation additions have been added since Java 8 (and even some Java 8 stuff is still missing). I am working on a detailed list of differences between GWT HEAD and Java 11 source whenever I find time for it. This is not really a blocker, but if we state GWT supports Java 11 we might want to have the most useful API additions available.

Automated releases that are tested like the SNAPSHOT builds, but with a fixed version number would be the solution to GWTs slow (fully tested) release cycle.

-- J.

[David Nouls]

I am using var in some simple cases and the gwt compiler did not have a problem. I don’t use them on lambda parameters though. So my code is using  Java 10 but not 11 features.

For the emulation changes I can live with what is available now and get some more in a later release. But how does the gwt team decide which are crucial and which ones can be done in a separate library ? The java.time API should really be considered, the Date object has been deprecated for ages. Right now I use moment.js with a JsInterop mapping to handle dates and times.

And yes please updates on a regular release cycle is the approach that many big projects use. As long as it has been tested wel, and GWT is as far as I have seen over all these years.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4414c464-fd70-4229-9876-f700c28d4df6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jens]

For the emulation changes I can live with what is available now and get some more in a later release. But how does the gwt team decide which are crucial and which ones can be done in a separate library ? The java.time API should really be considered, the Date object has been deprecated for ages. Right now I use moment.js with a JsInterop mapping to handle dates and times.

It is generally preferred to have JRE emulation within GWT itself instead of having separate libraries. Basically a single source of trust, which is well reviewed, tested and optimized. Also J2CL uses the same emulation and it might be beneficial to have J2CL experts take a look at the emulation code as well.

There was someone who did java.time emulation but he never contributed it. It was based on the threeten repository on Github. Personally I think java.time should really be tackled by GWT because working with Date in Client code is a pain. Using momentjs works, however it is still a pain for code you want to share between client and server. (There is also a java.time emulation on Github somewhere which uses momentjs under the hood I believe)

-- J.

[David Nouls]

Is it acceptable that an official GWT implementation of the time API would be based on moment.js ? Or is it expected that it is all implemented with standard browser API and pure Java code ?

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5fcf5659-b317-42bf-9ed9-61b3ca42b061%40googlegroups.com.

[Jens]

Is it acceptable that an official GWT implementation of the time API would be based on moment.js ? Or is it expected that it is all implemented with standard browser API and pure Java code ?

Because GWT compiler can not see/optimize external JS files, an official GWT implementation will likely also be based on the threeten code, thus java. I think the major hurdle is the ZoneId API for time zones. You don't want whole tzdata in your app if you just need one or a couple time zones.

-- J.

[Thomas Broyer]

I'd vote for only supporting zone offsets at first.