Summary: | Annotations should be a compilation dependency | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Walter Harley <eclipse> | ||||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | enhancement | ||||||||||
Priority: | P3 | CC: | david_audel, jgarms, Olivier_Thomann, paul.fullbright, vpiskarov | ||||||||
Version: | 3.2 | ||||||||||
Target Milestone: | 3.5 M5 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Walter Harley
2006-07-05 19:31:02 EDT
*** Bug 223497 has been marked as a duplicate of this bug. *** Please consider raising severity of this bug. This bug is a real show-stopper for us. Consider a very simple annotation processor validating that each field annotated with @Reference should have a type annotated with @Referable (a variation on 'dependency injection' theme). This basic processor is not going to work in incremental build mode. For example, if we remove @Referable annotation on some class the classes which depend on that class (including classes with @Reference fields referring that class) will not be recompiled and our validating processor will not even be called so no errors will be flagged to the user. Thus the referential integrity of our model will be compromised. The only workaround being the full build is really unacceptable as it ruins the user experience and will not scale on large projects. DI is an interesting use case for this feature. Can you clarify the expectation? I'm imagining you have something like: @Reference(Foo.class) class Bar { ... } and then you are expecting that if annotations on Foo change, the compiler should recompile Bar? Presumably it would not work if the class were referred to by name alone, e.g., @Reference("com.you.Foo") class Bar { ... } Walter, I meant something like that: @Referable class Foo { ... } class Bar { @Reference Foo foo; } in which case an instance of Foo will be injected by DI container into the field 'foo'. The invariant being 'each field annotated with @Reference should refer to a @Referable class'. So if @Referable is removed from 'Foo' our processor should flag an error on 'Bar.foo'. Another use case. Parameter types of @WebMethod methods should be annotated with @XmlRootElement (from JAXB). I.e.: @WebService class Foo { @WebMethod void foo(Bar bar); } @XmlRootElement class Bar { ... } So if @XmlRootElement is removed from 'Bar' our processor should flag an error on 'bar' parameter of 'Foo#foo' method. So, in all these cases you have a normal compilation dependency (that is, the compiler clearly knows it has a type dependency); no enhancement of the dependency computation is needed, rather it's a matter of broadcasting annotation changes in the same way that, e.g., changing the type hierarchy of the annotated type would be broadcast. Exactly! Created attachment 121111 [details]
test case
Here's a patch for org.eclipse.jdt.apt.tests, that demonstrates the problem. The test case in this patch currently fails.
I'll try and write a jdt.core (not APT) test to verify this - I figured I'd start with something I knew well.
Created attachment 121159 [details]
Proposed patch
Created attachment 121479 [details]
Test cases
Here's a suite of test cases that run in org.eclipse.jdt.core.tests.builder. These tests fail without the proposed patch, and pass with it.
Note that they (of course) require a 1.5 VM.
I've also modified BuilderTests to include the new test cases, in the 1.5 section.
One question: I don't really understand why changing an annotation on an inner type X within type A causes type B to be recompiled, if B references A (but not A.X). Is it because dependencies are managed on the basis of compilation units rather than types? It's working fine, I'm just wondering why.
> Is it because dependencies are managed on the basis of compilation units rather than types?
Correctamondo
Type dependencies take too much space & since we end up recompiling the entire compilation unit - why bother ?
Fix and tests released for 3.5M5 Verified for 3.5M5 using I20090126-1300 |