Last call for 2.8.0-RC3

[Daniel Kurka]

Hi all,

I will be cutting rc3 tomorrow 1pm CEST, please respond to this email with any outstanding reviews that you want to see included.

-Daniel

[Thomas Broyer]

Hi Daniel,

https://gwt-review.googlesource.com/16760 and https://gwt-review.googlesource.com/16800

[Kay-Uwe Janssen]

Is there a plan to fix the ValdiationTool (issue mentioned here: https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/lue7vRkkxU8 ) for default and static methods in proxy interfaces? or is it already fixed?

if one it should be documented as known issue with the @SkipInterfaceValidation workaround mentioned.

[Daniel Kurka]

This is a last call for patches, anything that is not in until tomorrow (and is not important enough to hold the release) will not get in.

Is there already a patch in review for this?

--
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/4a949505-2cc9-42b1-9a01-b8c71ed18bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

This is not a fix but a request for enhancement (unless I misremember). This is not "officially" supported, but it happens to work if you suppress validation for those methods.

[Arnaud TOURNIER]

I have one problem which is recurring, related to JsInterop.

Sometimes the JsInterop JS stub is not generated because of (seemingly) an internal error in SuperDevMode (and GWTC it seems), but nothing is logged, so it's difficult to diagnose.

For example, in an application (which does not inherits the User module), when i write a class like this, the JS stub is generated correctly :

@JsInterop

public class Toto

{

    public void doSomething()

    {

        // really nothing here...

    }

}

But if i change it to :

@JsInterop

public class Toto

{

    public void doSomething()

    {

        Window.alert( "yeah" );

    }

}

Then the JS stub is not generated (i mean the Toto constructor function is not made available to JS scope).

I understand that Window.alert(...) is implemented in the User module and since i don't inherit from it, the thing cannot be generated. But no message is generated (neither by SDM nor by the GWTC if i remember well), which is then difficult to diagnose...

Note : i should be able to produce a minimal repro case for this thing.

Then sometimes, a @JsInterop class would not be exported to JS, but if i change its name then it's generated, which is... weird.

For this one i am not sure i can give a minimal repro case because it happens on quite large projects (angular2 with gwt 2.8)...

I saw another error:

It was in a @JsInterop class, which called a template method (i mean with <T> in the signature of the method). I had to specify the <T> type to call it to have the SDM generating the class. If i didn't, the javac would infer correctly the <T> type (so no error appears in the IDE, which is Eclipse in my case), but it seemed that SDM did not manage to infer the type correctly because then the class would not be accessible from javascript... I can give you a sample file if you need.

A last one : i tried migrating a big app from 2.7 to 2.8-rc2 (same problem with previous sub versions of the 2.8). The compiler goes on compiling then does the linking, but it suddenly crashes without saying anything (i tried TRACE and DEBUG log levels with no more useful information) and results in a maven build failure. The build is happening in maven. Since the app is quite big, i guess the problem comes from a dependency i use which is not 2.8 friendly (did not have enough time to investigate that deeply). But again, the problem is not that the compile does not work, but that no useful message is generated to understand the error.

For this one, i can give you the code, but privately since it is a business app that is not open source...

Thanks !

Arnaud Tournier

LTE Consulting

[Roberto Lublinerman]

Arnaud, have you tried using -strict? GWT ignores compilation units with errors if they are not explicitly reachable from the entry point. I assume your Toto class is only referenced from JS. So if this class has any compile error (like missing references) then GWT does not see the class, much less know it is a JsType. Strict mode should give you an error in this case.

--

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-contributors+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5e5b6585-aba1-48ce-a5d6-6f9a702e801b%40googlegroups.com.

[Thomas Broyer]

As we've delayed the release a bit, let's add another documentation fix: https://gwt-review.googlesource.com/16860

On Thursday, September 8, 2016 at 4:27:36 PM UTC+2, Daniel Kurka wrote:

[Arnaud TOURNIER]

Thank you I will try that -strict option.

My suggestion is that exported @JsType (when the -generateJsExport option is turned on) should be considered as entrypoints and generate compilation errors, what do you think ?

[Jens]

Thank you I will try that -strict option.

My suggestion is that exported @JsType (when the -generateJsExport option is turned on) should be considered as entrypoints and generate compilation errors, what do you think ?

I think that -strict should be the default everywhere. I don't really see any value at all in not using -strict. Maybe some people do but then they should disable -strict. I use it since I use GWT and never had a reason to not use it.

-- J.

[Arnaud TOURNIER]

Makes sense! So better to have a "nostrict" option for the special cases
Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/33Zw3nP3q7o/unsubscribe.
To unsubscribe from this group and all its topics, 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/d28e825a-c095-4812-a1c8-99527ba88f06%40googlegroups.com.

[Jakob Jarosch]

Hi,
even it is a bit late, but we where a bit surprised that a merge request, opened half a year ago, was still not merged.
The bug forces us to maintain our own GWT.
https://gwt-review.googlesource.com/#/c/14430/

And then some not so important things (but its really sad, that no one cares about the merge requests...):
https://gwt-review.googlesource.com/#/c/11520/
https://gwt-review.googlesource.com/#/c/11470/
https://gwt-review.googlesource.com/#/c/11414/
https://gwt-review.googlesource.com/#/c/11460/

Yes, I can see some of them are now in a merge conflict state, but a year ago they were not.
I can see that this looks for everyone as a Google only project when nothing gets reviewed/merged. So it's no surprise that no one is motivated to contribute.

Regards,
Jakob

On Saturday, September 10, 2016 at 3:35:37 PM UTC+2, Arnaud TOURNIER wrote:

Makes sense! So better to have a "nostrict" option for the special cases
Thanks

Le sam. 10 sept. 2016 14:57, Jens <jens.ne...@gmail.com> a écrit :

Thank you I will try that -strict option.

My suggestion is that exported @JsType (when the -generateJsExport option is turned on) should be considered as entrypoints and generate compilation errors, what do you think ?

I think that -strict should be the default everywhere. I don't really see any value at all in not using -strict. Maybe some people do but then they should disable -strict. I use it since I use GWT and never had a reason to not use it.

-- J.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/33Zw3nP3q7o/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Freddy Boucher]

+1 for https://gwt-review.googlesource.com/#/c/14430/

It's a big one!

I opened a GitHub ticket for it: https://github.com/gwtproject/gwt/issues/9427

Thanks

[Kirill Prazdnikov]

One of above is a licensing issue (a missing one). 

Is it important ? 

[Kirill Prazdnikov]

Another one is about Event.BUTTON_LEFT processing. 

This seems to be important since to should be spec-ed somehow, it is ? 

[Jakob Jarosch]

Manolo reviewed https://gwt-review.googlesource.com/#/c/14430/, we did the requested changes.
Would be great if it gets merged before GWT 2.8 is released.