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
On 2011/02/17 03:44:31, jbrosenberg wrote:
I think generators do care about annotations that might exist in a
class (e.g.
in ClientBundle, @Source()).
I was thinking about the generator problem when I named this
ClassVisitor 'CompileDependencyVisitor'. We can add a
GeneratorDependencyVisitor next (but I thought you tried this and it was
too expensive?)
http://gwt-code-reviews.appspot.com/1359802/diff/4/5#newcode160
dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java:160:
int mask =
On 2011/02/17 01:03:38, scottb wrote:
Make into a class-level constant?
Done.
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
On 2011/02/17 03:44:31, jbrosenberg wrote:
Yes, agreed, the ClientBundle generator, for instance, definitely
depends on
knowing if there's been a change in an annotation, e.g.
@Source("sourceName")
I think I was confused originally this Opcodes.ACC_ANNOTATION indicates
this is a definition of the form
@interface Foo {}
not that it actually contains an annotation. To get that, you have to
implement the MethodVisitor and FieldVisitor
http://gwt-code-reviews.appspot.com/1359802/diff/4/5#newcode173
dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java:173:
On 2011/02/17 03:44:31, jbrosenberg wrote:
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?
The ASM code calls the visitors in the order the bytecode appears. Toby
says there is no requirement to sort methods by the compiler. I was
afraid that it could be that the order of methods appearance in a source
file affects the order in the byte code, or some other factor impacts
the order (like walking a hash table to dump the data)
If we assume that most classes are small, that it in theory, the sort
shouldn't have much impact.
http://gwt-code-reviews.appspot.com/1359802/diff/4/5#newcode202
dev/core/src/com/google/gwt/dev/javac/BytecodeSignatureMaker.java:202:
public String getClassDependencySignature(byte[] byteCode) {
On 2011/02/17 01:03:38, scottb wrote:
Make static?
Done.
http://gwt-code-reviews.appspot.com/1359802/diff/4/6
File
dev/core/test/com/google/gwt/dev/javac/BytecodeSignatureMakerTest.java
(right):
http://gwt-code-reviews.appspot.com/1359802/diff/4/6#newcode590
dev/core/test/com/google/gwt/dev/javac/BytecodeSignatureMakerTest.java:590:
private boolean compareUnitSignature(String originalSignature,
On 2011/02/17 01:03:38, scottb wrote:
If you formulate this as assertSignaturesEqual/NotEqual and call
assertEquals()
internally, you get a clearer exception than assertTrue/False gives.
(Although,
visually seeing the difference in hashes wouldn't be that useful;
you'd want to
compare the results of a for-testing
BytecodeSignatureMaker.getRawSignature().)
Done.
http://gwt-code-reviews.appspot.com/1359802/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
