Bug 223497 - Annotation change does not trigger recompilation
Summary: Annotation change does not trigger recompilation
Status: RESOLVED DUPLICATE of bug 149768
Alias: None
Product: JDT
Classification: Eclipse Project
Component: APT (show other bugs)
Version: 3.3.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Generic inbox for the JDT-APT component CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-21 10:45 EDT by Vladimir Piskarev CLA
Modified: 2008-03-27 13:17 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Piskarev CLA 2008-03-21 10:45:58 EDT
Build ID: M20071023-1652

Steps To Reproduce:
1. In a Java project, create annotation Foo and classes Bar, Baz:

public @interface Foo
{
}

public class Bar
{
}

public class Baz
{
    Bar bar;
}

Build the project (if auto-build is off).

2. Annotate class Bar with @Foo:

@Foo
public class Bar
{
}

Build the project incrementally (if auto-build is off).

3. Note that class Baz (which depends on Bar) has not been recompiled.


More information:
Now annotation change for class, field or method is not considered as structural change (see ClassFileReader#hasStructuralChanges). But it becomes increasingly important to consider it as such in context of internal DSLs in Java. For example, a root entity may aggregate some other entities. In this case, the root entity is responsible for aggregate validation and should be recompiled each time its child entities are changed - including any metadata changes in child entities.
Comment 1 Philipe Mulet CLA 2008-03-26 08:26:43 EDT
Unless I am mistaken, Baz is not affected by the addition of an annotation on Bar (only if it was @Deprecated, which we handle already).

Why would it need to be recompiled from a pure Java standpoint ?
Comment 2 Vladimir Piskarev CLA 2008-03-27 10:01:34 EDT
My apologies for the vague description. You are absolutely right - 'Baz' doesn't need to be recompiled from a pure Java standpoint, its class file is not affected by the change. The problem is the APT doesn't get called on 'Baz' in this case. We have requirements to perform "aggregate" validation when "component" metadata changes. For example,

@Aggregate
class A 
{
    @Inject C c; // can @Inject only a @Component
}

@Component
class C {}

If 'C' is no longer a @Component we should report an error on 'A'. The example is somewhat contrived but illustrates some real use-cases we have. 

Maybe I should have posted this to APT, sorry.
Comment 3 Philipe Mulet CLA 2008-03-27 11:54:32 EDT
Moving to APT
Comment 4 Walter Harley CLA 2008-03-27 13:17:38 EDT
There's nothing APT can do to force recompilation if we're not even called.  This problem is basically a reflection of the fact that JDT does not think of annotation processing as "pure Java" (to quote Comment #1).

Resolving as duplicate of Bug 149768, which is a longstanding request for annotations to be considered as part of the structural profile of a type.  I'd welcome further discussion within that bug.

*** This bug has been marked as a duplicate of bug 149768 ***