http://gwt-code-reviews.appspot.com/1359802/diff/4/5
File dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java
(right):

http://gwt-code-reviews.appspot.com/1359802/diff/4/5#newcode76
dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java:76: //
ignore
I think generators do care about annotations that might exist in a class
(e.g. in ClientBundle, @Source()).

http://gwt-code-reviews.appspot.com/1359802/diff/4/5#newcode161
dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java:161:
~(Opcodes.ACC_ANNOTATION | Opcodes.ACC_DEPRECATED
Yes, agreed, the ClientBundle generator, for instance, definitely
depends on knowing if there's been a change in an annotation, e.g.
@Source("sourceName")

http://gwt-code-reviews.appspot.com/1359802/diff/4/5#newcode173
dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java:173:
Is there a reason why you need to create multiple StringBuilders, for
the header, fields and methods?  Could you just maintain one big
signatureBuilder, which might be less overhead?  I see you do sorting
here, but doesn't the ASM get visited in a repeatable order anyway, as
it is?   I think it's probably ok if the order of some methods get
swapped in a source file, if that results in a different signature, no?

http://gwt-code-reviews.appspot.com/1359802/show

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to