Re: [gwt-contrib] GWT compiler optimization breaks some lambdas
(just in case someone read this thread) This problem has already been fixed in 2.8.0-SNAPSHOT. Thanks. On Tuesday, October 27, 2015 at 9:17:47 PM UTC+1, Ignacio Baca Moreno-Torres wrote: > > At last! > https://github.com/ibaca/gwt-instantiable-inference-bug/blob/master/src/main/java/com/bacamt/ibaca/client/Bug.java > > As Roberto said, the problem seems to be the instantiability inference. > The project works correctly on draftCompile, but on optimized compile the > lambas parameters gets nullified. Alternatively, if you use anonymous > classes the code works too (code commented), actually, only an explicit > reference to the overlay type is required. > > At this point, it appear that the problem was not lambdas :( , but lambdas > facilitates to process object only referencing implicit types, which now > seems to be the problem. Probably both test that Ray said fixed the > problem, but only if the type used was the Overlay type (I didn't test > that). > > Thanks. > > On Tuesday, October 27, 2015 at 9:17:48 AM UTC+1, Ignacio Baca > Moreno-Torres wrote: >> >> Tests: >> >>- Create a variable with the lambda to fix type inference; did not >>work. >>- Add a EntryPointDataOverlay.create() factory (not called); did not >>work. >>- Add EntryPointData data = new EntryPointDataPojo() before lambda; >>did not work, but now data_0 is not null, but its methods return >>nulls. >>- Add EntryPointData data = EntryPointDataOverlay.create() before >>lambda call; did WORK! >> >> >> I think that with this new info I can create a sample case. Looks like >> the overlay without constructor/factory calls is the key point. We have lot >> of that overlays because we are using restygwt that uses overlays as return >> type, but you only need to add this overlays as a generic parameter in a >> MethodCallback interface, so the contractor/factory is never used in the >> application. >> >> >> Although we are NOT using JsInterop, this comment look the key, thanks, >> hope next post will be a sample project. >> >>> That said, if you are using JsInterop, and you have a type that is never >>> new'ed in Java, the compiler infers that is not instantiable and assumes it >>> is always null and optimizes accordingly. Types originating from JavaScript >>> need to be marked as JsType so that the compiler is aware and does not >>> assume they are null. >> >> >> On Monday, October 26, 2015 at 10:39:39 PM UTC+1, Roberto Lublinerman >> wrote: >>> >>> I did not use pretty style because I thought that this flag produces different result, I tested now and looks like the output is the same, but, I'm pretty sure that some flags changes this issues, optimize is obvious that fixes the problem, but I think that namespace=package also changes the result. >>> >>> In a nutshell there are optimizations on the Java AST and those are not >>> affected at all by -style or -Xnamespace. Optimizations that are related to >>> types, instantiability, devirtualization, etc, are done in the Java AST. >>> >>> Some optimizations in that JavaScriptAST might be affected by -style >>> (like DuplicateFunctionRemoval) but those I think they are mostly off. I >>> don't think -Xnamespace has any impact on optimizations. >>> >>> That said, if you are using JsInterop, and you have a type that is never >>> new'ed in Java, the compiler infers that is not instantiable and assumes it >>> is always null and optimizes accordingly. Types originating from JavaScript >>> need to be marked as JsType so that the compiler is aware and does not >>> assume they are null. >>> >>> >>> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ee4260fe-4da2-43ee-a97d-4607b582fe22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 more proper solution is to have "--generateJsInteropExports
" and let every app choose their own subset but I don't
have time to implement it and took the shortcut for the
"--generateJsInteropExports " case.
On Wed, Apr 13, 2016 at 6:16 AM, Paul Stockley wrote:
> 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 PM UTC-4, Goktug Gokdogan wrote:
>>
>> 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.
>>
>> On Tue, Apr 12, 2016 at 9:10 AM, Paul Stockley
>> wrote:
>>
>>> 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 12, 2016 at 11:48:11 AM UTC-4, Ignacio Baca
>>> Moreno-Torres wrote:
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 {
> 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.
>
> --
>>> 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+unsubscr...@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.
>>>
>>
>> --
> 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+unsubscr...@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
>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA10ELo6xyNhrC_5niCssA93m5j4Fjd7oXKBsNHrpz7jHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
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 PM UTC-4, Goktug Gokdogan wrote:
>
> 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.
>
> On Tue, Apr 12, 2016 at 9:10 AM, Paul Stockley > wrote:
>
>> 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 12, 2016 at 11:48:11 AM UTC-4, Ignacio Baca
>> Moreno-Torres wrote:
>>>
>>> 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 {
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.
--
>> 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+unsubscr...@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.
>>
>
>
--
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+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.
