JsInterop is pruning non readed properties

229 views
Skip to first unread message

Ignacio Baca Moreno-Torres

unread,
Apr 12, 2016, 9:57:10 AM4/12/16
to GWT Contributors
This code:
public class Client implements EntryPoint {
    Console log = Browser.getWindow().getConsole();

    @Override public void onModuleLoad() {
        Foo foo = new Foo();
        foo.bar = 666;
        log.log(foo);
    }
   
    @JsType public static class Foo {
        public int bar;
    }
}


Generate this js:

function $onModuleLoad(this$static){
  var foo;
  foo = new Client$Foo;
  $log(this$static.log_0, foo);
}


I.e.: the Foo.bar var is pruned. This makes this common case (IMHO) fail silently (an empty object is sent to the server):

Foo f = new Foo(); f.bar=666; request.send(f);


This can be fixed using isNative=true, which might be ok, but the important thing is that this code fails silently which is really annoying. Thanks.

Paul Stockley

unread,
Apr 12, 2016, 11:11:17 AM4/12/16
to GWT Contributors
Are you compiling with -generateJsInteropExports ?

Paul Stockley

unread,
Apr 12, 2016, 11:12:45 AM4/12/16
to GWT Contributors
Also, forgot to mention. I had quite a few issues with the Beta that went away in the latest snapshot build.

Ignacio Baca Moreno-Torres

unread,
Apr 12, 2016, 11:20:45 AM4/12/16
to GWT Contributors
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).

Ignacio Baca Moreno-Torres

unread,
Apr 12, 2016, 11:48:11 AM4/12/16
to GWT Contributors
Compiled using 2.8.0-SNAPSHOT and without -generateJsInteropExports.
With -generateJsInteropExport works! (i.e.: Foo.bar field is not pruned)

Paul Stockley

unread,
Apr 12, 2016, 12:10:43 PM4/12/16
to GWT Contributors
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.

Goktug Gokdogan

unread,
Apr 12, 2016, 12:51:12 PM4/12/16
to google-web-toolkit-contributors
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 Global object if the flag is not enabled. IIRC, it will also prune some unused Object instance members but that's not aggressive for performance reasons but also not enough since you might have a reference from Java code. I'm open to any suggestions.

--
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/a8fed9ee-8137-478d-92e7-1fe5ba1a7409%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Paul Stockley

unread,
Apr 13, 2016, 9:16:37 AM4/13/16
to GWT Contributors
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.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

Goktug Gokdogan

unread,
Apr 13, 2016, 11:55:58 AM4/13/16
to google-web-toolkit-contributors
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 more proper solution is to have "--generateJsInteropExports <class-patterns>" and let every app choose their own subset but I don't have time to implement it and took the shortcut for the "--generateJsInteropExports <all>" case.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

--
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/7ff73ac6-fbcc-47ad-8878-874b00191912%40googlegroups.com.

Paul Stockley

unread,
Apr 15, 2016, 9:13:44 AM4/15/16
to GWT Contributors
So are you saying they are using just JsType=native interfaces and the export flag is stopping these from being pruned?
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

--
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.

Goktug Gokdogan

unread,
Apr 15, 2016, 12:17:02 PM4/15/16
to google-web-toolkit-contributors
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.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

--
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.

--
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/7444ccb3-68fe-4f48-8b9e-9a16a54d19e0%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages