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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5ee8d98c-778e-4c71-a4e1-b7990ceb6523%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
