> - Could the GPE theoretically listen for changes to the classpath > and update the resource oracle specifically when they change > (eliminating the need to refresh when browser-refresh is called)?
FWIW, I've mulled over the same possibility--the GWT compile infrastructure seems very "batch"-oriented where everything (resource lookup/etc.) is constantly redone (granted, artifacts are aggressively cached, but the steps to get there are still constantly retraced). It seems like, as you say, listening for file changes and merging it into the existing ResourceOracle/TypeOracle state seems like it would be a lot faster. I saw Ray's G+ comment about listening to file changes for super dev mode, but my assumption is that it will still have to run a from-scratch compile. My impression is that moving away from a batch orientation is limited by the semantics of deferred binding--if you had a scenario: * Write Foo1 implements Foo * GeneratorA asks TypeOracle who impls Foo, sees Foo1 * GeneratorB creates Foo2 implements Foo Now hit refresh, with a non-batch/"keep the existing state and merge in changes", would mean that, with a naive implementation: * GeneratorA asks TypeOracle who impls Foo and now sees Foo1 + Foo2 So the semantics of your compilation have changed. While the unit cache already handles incremental compilation of the bytecode/GWT ASTs, it still does so by starting with a fresh Resource/TypeOracle. It seems like doing incremental modifications (based on file changes) to the Resource/TypeOracle would be non-trivial. I'm curious if the GWT team has thought through this; does that sound right? Is there something other than deferred binding that makes Resource/TypeOracle reuse untenable? Disclaimer that I've done no prototyping or profiling or even "more than musing" thinking about this, so, as Josh said, please excuse my ignorance. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
