Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

No, some "shared" libraries uses non-native JsType and passing the flag stopping from being pruned for the majority of the apps who doesn't care. On Fri, Apr 15, 2016 at 6:13 AM, Paul Stockley wrote: > So are you saying they are using just JsType=native interfaces and the

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

So are you saying they are using just JsType=native interfaces and the export flag is stopping these from being pruned? On Wednesday, April 13, 2016 at 11:55:58 AM UTC-4, Goktug Gokdogan wrote: > > Unfortunately, that is not true. A lot of people just need to deal with > native types without

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

Unfortunately, that is not true. A lot of people just need to deal with native types without any need for exporting their own types to JavaScript and shared libraries will start accumulating unnecessary code for all of them if it is enabled by default. We have already seen this Google. Actually

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

I agree that if you disable exports you can run into the same problem. However, I would guess most GWT users would have no reason to turn it off and in that case it would be consistent. It seems more an optimization for a use case most people won't have. On Tuesday, April 12, 2016 at 12:51:12

Re: [gwt-contrib] Re: JsInterop is pruning non readed properties

Changing the default will not solve the SDM vs Prod problem (i.e. what if I disabled it?). The default is sub-optimal but helps in the grand scheme of things (There is a comment thread in the Doc discussing why the default is chosen in the current way). SDM already doesn't export members to

[gwt-contrib] Re: JsInterop is pruning non readed properties

I think this flag in its current form is evil. If you forget it your code will work in SDM and not in production. I would recommend one of the following: 1) Have export on by default and have a flag to turn it off 2) or have SDM prune the non-exported classes from the code. On Tuesday, April

[gwt-contrib] Re: JsInterop is pruning non readed properties

Compiled using 2.8.0-SNAPSHOT and without -generateJsInteropExports. With -generateJsInteropExport works! (i.e.: Foo.bar field is not pruned) On Tuesday, April 12, 2016 at 3:57:10 PM UTC+2, Ignacio Baca Moreno-Torres wrote: > > This code: > public class Client implements EntryPoint { >

[gwt-contrib] Re: JsInterop is pruning non readed properties

This happens with the last snapshot and not, I'm not using ' -generateJsInteropExports'. There is a bit longer explanation and discussion in the gwt gitter room (https://gitter.im/gwtproject/gwt). On Tuesday, April 12, 2016 at 5:12:45 PM UTC+2, Paul Stockley wrote: > > Also, forgot to mention.

[gwt-contrib] Re: JsInterop is pruning non readed properties

Also, forgot to mention. I had quite a few issues with the Beta that went away in the latest snapshot build. On Tuesday, April 12, 2016 at 11:11:17 AM UTC-4, Paul Stockley wrote: > > Are you compiling with -generateJsInteropExports ? > > On Tuesday, April 12, 2016 at 9:57:10 AM UTC-4, Ignacio

[gwt-contrib] Re: JsInterop is pruning non readed properties

Are you compiling with -generateJsInteropExports ? On Tuesday, April 12, 2016 at 9:57:10 AM UTC-4, Ignacio Baca Moreno-Torres wrote: > > This code: > public class Client implements EntryPoint { > Console log = Browser.getWindow().getConsole(); > > @Override public void onModuleLoad() { >