Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

This tripped me up as well. I second adding a note to the Javadoc as Boris suggested. On Thursday, August 25, 2016 at 10:07:00 PM UTC+1, Goktug Gokdogan wrote: > > Document includes a comment about it in the examples and the section that > describes the migration from 2.7 has an instruction to

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

Document includes a comment about it in the examples and the section that describes the migration from 2.7 has an instruction to add the flag. On Mon, Aug 22, 2016 at 7:17 AM, Boris Brudnoy wrote: > Thanks guys. A note on this should certainly make it into the

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

Thanks guys. A note on this should certainly make it into the public JsInterop doc, somewhere close to the definition of the JsType/JsMethod/JsProperty contract. On Mon, Aug 22, 2016 at 8:04 AM Jens wrote: > > Jens is spot on. We want people to explicitly use >>

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

> Jens is spot on. We want people to explicitly use > -generateJsInteropExports if they rely on exporting since it has a hit on > code size. > Maybe the mention of the parameter should be added to the JsType JavaDoc for a final 2.8 release. -- J. -- You received this message because you

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

Jens is spot on. We want people to explicitly use -generateJsInteropExports if they rely on exporting since it has a hit on code size. On Mon, Aug 22, 2016 at 12:56 PM Thomas Broyer wrote: > FWIW, I believe this is >

[gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

FWIW, I believe this is https://github.com/gwtproject/gwt/commit/ca8ad7bc140bc23b237620c41d755ef787bd97b1 (i.e. on-purpose) On Friday, August 19, 2016 at 9:38:32 PM UTC+2, Jens wrote: > > @JsType with isNative = false (the default) are probably treated as normal > classes now if you do not

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

Because all these non native JsTypes are considered entry points to your application when they are exported and thus all code referenced by them can not be pruned and maybe some other optimization a can't be applied to it as well. Now consider GWT libraries that use non native JsTypes to export

Re: [gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

Yes, field names return to being named in JavaScript as declared in Java after the addition of the -generateJsInteropExports compiler parameter. Why isn't this the default compiler behavior, though? After all, I followed the JsInterop spec, which, in @JsType section

[gwt-contrib] Re: A possible JsInterop issue in GWT 2.8 RC2

@JsType with isNative = false (the default) are probably treated as normal classes now if you do not use -generateJsInteropExports as compiler parameter. I guess it works again if you use the compiler parameter? -- J. -- You received this message because you are subscribed to the Google