Your stack trace stops just before where the issue is happening, but the GWT compiler believes that you are using code in an impossible way, and is forced to emit an error message to correctly compile out impossible code. Roughly, the "throw ClassCastException unless null" check means that there is some cast that must always fail - nothing ever implements the interface, or nothing ever calls the constructor. In draft mode, the compiler couldn't prove this, but when you were building for production, the compiler is confident that this is impossible.
What is likely happening is that you are doing an unchecked cast of some kind, possibly a native JS type to a @JsType-annotated interface that isn't marked as isNative=true or the like. In this scenario, the compiler knows that no native types could implement the interface, and since it sees no non-native types that implement it, there must be no such types, so any calls to the interface's methods are actually errors. Further, any code that would come after such a method call can never be called. Look at the next frame up the stack trace, and see if you can tell what method call is being optimized out in this way. Probably you'll see that it either comes from a class or interface that can't be directly instantiated, but somehow (likely an unchecked cast) you have an instance of that type anyway. As to correctness, this is a good check to have, as it removes impossible code, which _usually_ you don't want to have. Incorrect code can often lead to impossible code, but there are many reasonable cases where this check should be emitted, so it isnt necessarily wrong for a compiled application to have this. On Friday, June 16, 2023 at 2:25:53 PM UTC-5 nikola wrote: > Some class cast exception... > > Showing dialog with error2 Error: java.lang.ClassCastException > at ClassCastException.createError (lw_ui-0.js:2052:10) > at ClassCastException.initializeBackingError (lw_ui-0.js:2078:40) > at ClassCastException.Throwable_0 (lw_ui-0.js:2017:8) > at ClassCastException.Exception_0 (lw_ui-0.js:2095:15) > at ClassCastException.RuntimeException_0 (lw_ui-0.js:16350:15) > at new ClassCastException (lw_ui-0.js:217687:22) > at checkCriticalType (lw_ui-0.js:225523:16) > at throwClassCastExceptionUnlessNull (lw_ui-0.js:272:3) > > It works with -draftCompile. What we are potentially losing having code > compiled with -draftCompile? Is it safe to have it on production? > > On Friday, June 16, 2023 at 7:36:50 PM UTC+2 Colin Alworth wrote: > >> Super Dev Mode skips many optimizations, both to decrease compile times >> and also to make incremental compilations possible - it isn't possible to >> make SDM behave the exact same as a production compile. One way you can get >> close is to specify -draftCompile (how you specify it may vary based on how >> you run the compiler) so that the production build skips many optimizations. >> >> Can you elaborate on what the strange error is? >> >> On Friday, June 16, 2023 at 11:32:37 AM UTC-5 nikola wrote: >> >>> Hello, >>> >>> The code has passed in development mode but when it's deployed I got an >>> strange error. Is there a difference in generated compiled code when >>> deployed and code in development mode ? >>> And if true, where can I change that setting to have it equals >>> >> -- You received this message because you are subscribed to the Google Groups "GWT Users" 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/9b14eb34-183d-49c6-bbb3-9748d41c514cn%40googlegroups.com.
