Almost there
http://gwt-code-reviews.appspot.com/1236801/diff/39001/40001 File dev/core/src/com/google/gwt/core/ext/typeinfo/JRealClassType.java (right): http://gwt-code-reviews.appspot.com/1236801/diff/39001/40001#newcode28 dev/core/src/com/google/gwt/core/ext/typeinfo/JRealClassType.java:28: void addByteCode(byte[] byteCode); Why is this method in the public interface? Can we just remove it and leave the implementation in typemodel.JRealClassType? http://gwt-code-reviews.appspot.com/1236801/diff/39001/40003 File dev/core/src/com/google/gwt/dev/javac/rebind/CachedClientDataMap.java (right): http://gwt-code-reviews.appspot.com/1236801/diff/39001/40003#newcode39 dev/core/src/com/google/gwt/dev/javac/rebind/CachedClientDataMap.java:39: // this will throw a ClassCastException if value is not Serializable Comment is pointless as is. Document with javadoc instead? http://gwt-code-reviews.appspot.com/1236801/diff/39001/40008 File dev/core/src/com/google/gwt/dev/javac/typemodel/JRealClassType.java (right): http://gwt-code-reviews.appspot.com/1236801/diff/39001/40008#newcode290 dev/core/src/com/google/gwt/dev/javac/typemodel/JRealClassType.java:290: lazyTypeStrongHash = Util.computeStrongName(byteCode); This isn't exactly what we want either, but it's better than assuming always stale or taking a long time to compute a hash. Can you add a comment here that explains that ideally we want to identify staleness based on a type's structure, not including its code, but we don't have a quick way to compute a hash for type structure yet? http://gwt-code-reviews.appspot.com/1236801/diff/39001/40013 File user/src/com/google/gwt/resources/ext/SupportsGeneratorResultCaching.java (right): http://gwt-code-reviews.appspot.com/1236801/diff/39001/40013#newcode41 user/src/com/google/gwt/resources/ext/SupportsGeneratorResultCaching.java:41: public interface HasFindableResourceDependencies extends It's cute, but is there actually a benefit to nesting this? http://gwt-code-reviews.appspot.com/1236801/diff/39001/40014 File user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java (right): http://gwt-code-reviews.appspot.com/1236801/diff/39001/40014#newcode232 user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:232: for (JClassType superType : superTypes) { Why is this for loop necessary? Doesn't getFlattenedSupertypeHierarchy already do this? http://gwt-code-reviews.appspot.com/1236801/diff/39001/40014#newcode249 user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:249: if (!(type instanceof JRealClassType)) { Under what situations does this occur? http://gwt-code-reviews.appspot.com/1236801/diff/39001/40014#newcode510 user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:510: * Loop through each of our ResouceGenerator classes, and check those that s/that that/that http://gwt-code-reviews.appspot.com/1236801/diff/39001/40014#newcode532 user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:532: // use the jar file itself for the modified date test Document why http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
