Unit Cache doesn't take binary annotations into account

[dankurka]

Originally reported on Google Code with ID 6646

Found in GWT Release (e.g. 1.5.3, 1.6 RC):
GWT 2.4 rc1

Detailed description (please be as specific as possible):

From stephen.haberman:

On Tue, Aug 2, 2011 at 2:57 PM, Stephen Haberman wrote:
> Hi,
>
> I ran into an odd boundary case with the unit cache today that I
> thought I'd report.
>
> I had a class, Foo, using a binary-only annotation, @Bar. Somehow
> my classpath was wrong, and so I got a (valid) compilation error
> from ecj that Foo couldn't be compiled without Bar.
>
> However, after fixing my classpath issue, the compilation error
> didn't go away. After several minutes of ensuring the classpath was,
> no really, really right now, I finally realized it's because binary
> only annotations are not captured by the CompilationUnit's Dependencies
> (being resolved against the valid classes found by the resource oracle,
> which won't have binary-only annotations), so I was really seeing
> cached compilation errors.
>
> Adding a blank line to Foo kicked off a real compilation and then
> all was well.
>
> I don't have any insights on how to recognize this case, nor if
> it's worth doing so, given it is likely/hopefully rare.

Links to relevant GWT Developer Forum posts:

https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/hs74eF8rlwks

Reported by zundel@google.com on 2011-08-02 19:43:03

[dankurka]

I see how that could happen.  We don't take annotations into account
in the computing of dependencies in

BytecodeSignatureMaker.CompileDependencyVisitor.

Reported by zundel@google.com on 2011-08-02 19:43:41

[dankurka]

Hm...I'm not sure if BytecodeSignatureMaker including annotations would fix the issue?

In my case, Foo's bytecode didn't change, so I don't think the hash including/not including
annotations affected anything.

It was only the presence of those annotations on ecj's classpath that changed.

(AFAIK, this type of change is typically detected by Dependencies.validate, where,
if the annotation had not been binary, it would have initially resolved as null, but
then resolved as non-null when the classpath was fixed, thereby triggering a recompilation
of Foo even though Foo's source and bytecode had not changed.)

Unless the BytecodeSignatureMaker hash conditionally included binary annotations based
on whether they were actually available on the classpath. If so, then the hash would
have changed, and Foo would have been recompiled.

Reported by stephen.haberman on 2011-08-02 21:25:20

[dankurka]

Reported by zundel@google.com on 2011-10-11 00:53:09

• Status changed: PatchesWelcome

[dankurka]

@Stephan not sure what to do with this, any hints?

Reported by dankurka@google.com on 2013-05-28 01:11:02