(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 [email protected]. 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.
