Scott makes sense, however, would it not also make sense to have a signature that can also used by generators to determine whether a type has changed (and prevent the need for an alternate signature being maintained for that purpose)? Currently, we have a dumbed down version of generating a signature from the full bytecode (in JRealClassType). That would benefit from an asm based signature that only looks at api level structure....Perhaps this present code could be modified to alternately accept a flag to consider annotations as well, if desired.
I'm wondering if handling the case where some methods have been re-ordered in a source file is worth incurring the overhead of sorting and managing multiple StringBuilders, etc. This could add up if we have a large number of classes to consider, etc. I'm not sure how often a source file has some fields/methods re-ordered, vs. other api changing edits, or how important it is to seamlessly handle that case (I think the user expects some recompiling when editing code). Maybe it's not too expensive though (in which case I'll go jump off a cliff)? How long on average does it take to generate a signature with this code? I think that should be a design consideration too. Eric, do you have any timing numbers on that? http://gwt-code-reviews.appspot.com/1359802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
