Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext
the ModuleDefLoader/DOM "downgrade" was in the GWT 2.6 release branch only (since 2.6 is strictly expected to maintain compatibility). The GWT 3.0 branch was not changed. GWT 3.0 is more open to backwards incompatible changes and I agree/fully expect that for the 3.0 release the right thing to do will be to update the Designer code base to account for to match the GWT 3.0 release. On Mon, Feb 10, 2014 at 3:55 PM, Colin Alworth wrote: > Thanks for the reply - I'll keep watching ;). > > W.R.T. designer, since existing installs are already broken and GWT 3+ is > going to again remove these deprecated methods, wouldn't it make more sense > to upgrade designer rather than downgrade ModuleDefLoader/DOM? (Keeping in > mind that I don't know what other upcoming changes are coming, but I'm > assuming that code like ModuleDefLoader will eventually have some > advantages from the context objects, and designer can't just keep using > this now-deprecated method forever.) > > On Monday, February 10, 2014 3:02:00 PM UTC-8, John Stalcup wrote: > >> >> >> >> On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth wrote: >> >>> Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, >>> but I've also seen this trying to understand the general compiler changes >>> that are happening in trunk gwt - is the CompilerContext really an >>> essential part of ModuleDefLoader in general? From what I can see it is >>> tracked as a local variable, but only used in the enforceStrictResources() >>> check, which could just as easily be a boolean. For any synthetic module >>> (which can't have any resources at all), this is a moot point so the >>> context could be skipped entirely, and more generally it *seems* to just be >>> a flag. >>> >> not all changers are in. there are more uses coming. >> >>> >>> CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and >>> passes it to the JdtCompiler, which doesn't actually use it at all - that >>> seems to be the extent of its use when you do a >>> ModuleDef.getCompilationState (which now requires that context as an >>> argument, even though the ModuleDef already should have that state from the >>> previously mentioned ModuleDefLoader?). Precompile takes it to get the >>> module and the options (instead of taking the module and the options), and >>> the J2JSCompiler takes it just to read options. >>> >>> At least as of 2.6 branch, haven't done the same tracing through master >>> just yet. >>> >>> So my question is two-fold: Is this the new way of avoiding too many >>> sets of config types to track, and if so, why restore the old APIs so that >>> the designer can use them in 2.6.1 instead of updating the designer to >>> generate a simple context for its own needs? >>> >> updating the designer code would leave existing designer installs broken. >> >> >>> Assuming this is the future way of dealing with options/etc, won't the >>> designer just break again as this becomes more and more necessary to hook >>> into the compiler from outside? >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> --- >>> 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 >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext
Thanks for the reply - I'll keep watching ;). W.R.T. designer, since existing installs are already broken and GWT 3+ is going to again remove these deprecated methods, wouldn't it make more sense to upgrade designer rather than downgrade ModuleDefLoader/DOM? (Keeping in mind that I don't know what other upcoming changes are coming, but I'm assuming that code like ModuleDefLoader will eventually have some advantages from the context objects, and designer can't just keep using this now-deprecated method forever.) On Monday, February 10, 2014 3:02:00 PM UTC-8, John Stalcup wrote: > > > > > On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth > > wrote: > >> Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, >> but I've also seen this trying to understand the general compiler changes >> that are happening in trunk gwt - is the CompilerContext really an >> essential part of ModuleDefLoader in general? From what I can see it is >> tracked as a local variable, but only used in the enforceStrictResources() >> check, which could just as easily be a boolean. For any synthetic module >> (which can't have any resources at all), this is a moot point so the >> context could be skipped entirely, and more generally it *seems* to just be >> a flag. >> > not all changers are in. there are more uses coming. > >> >> CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and >> passes it to the JdtCompiler, which doesn't actually use it at all - that >> seems to be the extent of its use when you do a >> ModuleDef.getCompilationState (which now requires that context as an >> argument, even though the ModuleDef already should have that state from the >> previously mentioned ModuleDefLoader?). Precompile takes it to get the >> module and the options (instead of taking the module and the options), and >> the J2JSCompiler takes it just to read options. >> >> At least as of 2.6 branch, haven't done the same tracing through master >> just yet. >> >> So my question is two-fold: Is this the new way of avoiding too many sets >> of config types to track, and if so, why restore the old APIs so that the >> designer can use them in 2.6.1 instead of updating the designer to generate >> a simple context for its own needs? >> > updating the designer code would leave existing designer installs broken. > > >> Assuming this is the future way of dealing with options/etc, won't the >> designer just break again as this becomes more and more necessary to hook >> into the compiler from outside? >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> --- >> 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 >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] ModuleDefLoader changes and CompilerContext
On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth wrote: > Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but > I've also seen this trying to understand the general compiler changes that > are happening in trunk gwt - is the CompilerContext really an essential > part of ModuleDefLoader in general? From what I can see it is tracked as a > local variable, but only used in the enforceStrictResources() check, which > could just as easily be a boolean. For any synthetic module (which can't > have any resources at all), this is a moot point so the context could be > skipped entirely, and more generally it *seems* to just be a flag. > not all changers are in. there are more uses coming. > > CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and > passes it to the JdtCompiler, which doesn't actually use it at all - that > seems to be the extent of its use when you do a > ModuleDef.getCompilationState (which now requires that context as an > argument, even though the ModuleDef already should have that state from the > previously mentioned ModuleDefLoader?). Precompile takes it to get the > module and the options (instead of taking the module and the options), and > the J2JSCompiler takes it just to read options. > > At least as of 2.6 branch, haven't done the same tracing through master > just yet. > > So my question is two-fold: Is this the new way of avoiding too many sets > of config types to track, and if so, why restore the old APIs so that the > designer can use them in 2.6.1 instead of updating the designer to generate > a simple context for its own needs? > updating the designer code would leave existing designer installs broken. > Assuming this is the future way of dealing with options/etc, won't the > designer just break again as this becomes more and more necessary to hook > into the compiler from outside? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] ModuleDefLoader changes and CompilerContext
Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, but I've also seen this trying to understand the general compiler changes that are happening in trunk gwt - is the CompilerContext really an essential part of ModuleDefLoader in general? From what I can see it is tracked as a local variable, but only used in the enforceStrictResources() check, which could just as easily be a boolean. For any synthetic module (which can't have any resources at all), this is a moot point so the context could be skipped entirely, and more generally it *seems* to just be a flag. CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and passes it to the JdtCompiler, which doesn't actually use it at all - that seems to be the extent of its use when you do a ModuleDef.getCompilationState (which now requires that context as an argument, even though the ModuleDef already should have that state from the previously mentioned ModuleDefLoader?). Precompile takes it to get the module and the options (instead of taking the module and the options), and the J2JSCompiler takes it just to read options. At least as of 2.6 branch, haven't done the same tracing through master just yet. So my question is two-fold: Is this the new way of avoiding too many sets of config types to track, and if so, why restore the old APIs so that the designer can use them in 2.6.1 instead of updating the designer to generate a simple context for its own needs? Assuming this is the future way of dealing with options/etc, won't the designer just break again as this becomes more and more necessary to hook into the compiler from outside? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: GWT + Maven - Using gwt-dev package as dependency
Thank you Thomas and Colin for your replies. Thomas, sorry for posting in the wrong place. I didn't even know there is a gwt-maven-plugin users group... thanks for pointing that out! Working with separated projects with GWT, Maven, Eclipse (and his friends - the plugins!) and App Engine is really hard and sometimes frustrating... but when it works is really useful, mainly for environments with continuous integration. All hail to The Maven Way™! On Sunday, February 9, 2014 4:19:20 PM UTC-2, Thomas Broyer wrote: > > AFAICT, the warning originally was added because gwt-dev bundles various > dependencies, such as Xalan and Xerces, ECJ, Apache Commons, Jetty, etc. > that could conflict with dependencies you use for your server-side code. > That said, using the same project for client and server sides is a bad > idea, and violates The Maven Way™, so in practice gwt-dev should > effectively not be a problem. FWIW, I do believe that warning should be > removed. > > Also, BTW, you should have rather posted to the gwt-maven-plugin users > group, or the GWT users group. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] I am getting ClassCastException on my app production code, but not on dev mode.
Hi,
I am developing multiple apps with similar structure, they're working fine
except for 2. They give me the following error on production mode only:
Uncaught java.lang.runtimeexception: java.lang.ClassCastException
This is the compiled code that throws the exception:
function
com_google_gwt_core_client_impl_Impl_entry__Lcom_google_gwt_core_client_JavaScriptObject_2Lcom_google_gwt_core_client_JavaScriptObject_2(jsFunction){
return function(){
try {
return
com_google_gwt_core_client_impl_Impl_entry0__Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2(jsFunction,
this, arguments);
}
catch (e) {
throw e;
}
}
;
I am using GWT 2.5.1, any idea what could be the problem?
Thanks
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
