On Thu, Feb 17, 2011 at 12:22 AM, <[email protected]> wrote: > 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 have to agree that this should be separate. For example, TypeOracle cares about parameter names, annotations, etc; none of which would force recompile propagation. > 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)? > I'm sure it's not terribly expensive, and I'm generally not a fan of trying to micro optimize on the front end. If it becomes a source of sluggishness, it'll show up on profiling at some point. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
