Community
Participate
Working Groups
Build Identifier: Eclipse platform (3.5.2): M20100211-1343 (AJDT: 2.1.0.e35x-release-20100630-1500) When a Java project is converted to an "AspectJ" project, the default Java builder is replaced with an AJDT enhanced this builder. When Java files are modified, some compile errors are not updated correctly, giving false positives or negatives for the developer (i.e. a warning/error is not shown, or not removed when expected). Workaround is to clean the project manually to make sure no compile errors are present. This is of course very annoying and error prone, and basically means incremental compilation is broken for AspectJ enabled projects. Reproducible: Always Steps to Reproduce: I've included a sample project, see the attachment. 1. PlainJava depends on JavaClassWithPointsApplied. Open JavaClassWithPointsApplied and add " throws IOException" to publicFoo() method. 2. The problems view/package explorer does NOT show the problem in PlainJava (does not catch IOException). 3. Open PlainJava. The error marker is now shown. Note that some other operations (removing the method, for instance), does update correctly.
Created attachment 173417 [details] Example project to reproduce error
Created attachment 173419 [details] AJDT event trace corresponding to problems The AJDT Event trace shows that when adding a checked exception, corresponding files are not considered, resulting in the error. The trace shows that when a method is removed, corresponding files are considered correctly.
This may be an aspectj issue regarding how file dependencies are stored across incremental compiles. It may be that when a Java file in another project adds a new exception, this is not marked as a structural change. And there is no subsequent recompile of dependent source files.
yes, more likely to be AspectJ than AJDT - reassigning
Thanks for the comments, this lead me to do some additional testing. In summary: the following does not work: 1. Changing throws clause 2. Removing/adding Java class (inner or outer) 3. Changing a generic parameter type on a constructor, method or field. [1] I tried the following: class removed/added FAIL method removed/added PASS constructor removed/added PASS class visible/invisible PASS method visible/invisible PASS constructor visible/invisible PASS class static/non-static PASS method static/non-static PASS method return type change PASS method param type change PASS method generic return type change FAIL [1] method generic param type change FAIL constructor generic param type change FAIL method param added/removed PASS method throws clause changed FAIL field added/removed PASS field visible/invisible PASS field type change PASS field generic param type change FAIL inner class added/removed FAIL inner class visible/invisible PASS inner class static/non-static PASS class generic type param change PASS [2] method generic type param change PASS [1] Example: Change from List<String> to List<Long> [2] Example: Change from class Foo <T extends Number> to <T extends List>
given that no changes are being made to the aspect, its existence should be irrelevant (if it isn't that is another clue). Without the aspect we are reduced to pure-java, and AspectJ is based on the eclipse java compiler at heart for java compilation. This would suggest a problem with the eclipse compiler. Now AspectJ is based on an old level of the compiler (eclipse 3.3) so some of these things may be issues that exist in the old eclipse compiler that have been fixed since - AspectJ would need to rebase on a new version of the eclipse compiler to pickup their fixes.
Although it probably does not matter because it is now classified as an AspectJ bug, I did my last testing run on Eclipse 3.6, no difference from 3.5.2. We are using AJDT in a vanilla AspectJ setup, I retested this in a Spring Roo project and the problem is the same. Because aspects are happening automagically in Roo this might be even more confusing for Roo users, and makes incremental compilation unreliable there too. I retested without any aspects, the behavior is the same. Just 2 Java classes in the same project will do. I also tested with combinations of plain Java (standard JDT compiler) and AspectJ compiler projects. JDT -> AspectJ works fine, the other way around does not work.
(In reply to comment #6) > given that no changes are being made to the aspect, its existence should be > irrelevant (if it isn't that is another clue). Without the aspect we are > reduced to pure-java, and AspectJ is based on the eclipse java compiler at > heart for java compilation. This would suggest a problem with the eclipse > compiler. Now AspectJ is based on an old level of the compiler (eclipse 3.3) > so some of these things may be issues that exist in the old eclipse compiler > that have been fixed since - AspectJ would need to rebase on a new version of > the eclipse compiler to pickup their fixes. I have been on Eclipse since 1.0 and never experienced these kind of problems in JDT. To be sure, I downloaded Eclipse 3.3 classic from the archives and tried this in a plain Java project. The problems do not occur there. Maybe the AspectJ modifications to the compiler introduced these bugs? In that case, rebasing may not resolve the issue. This is just pure speculation on my part, I have no knowledge at all of the AspectJ compiler codebase.
Yep, I retried on 3.3 too and it didn't fail - so it is the way in which AspectJ is managing the rebuilding. We do need to upgrade from 3.3 at some point but thankfully we don't have to in order to fix these issues. The 'bundle' of generics related ones are likely because some incremental handling hasn't been revisited since it was first written for pre-Java5. > method throws clause changed fixed
> method generic return type change > method generic param type change > constructor generic param type change fixed
> field generic param type change fixed
(In reply to comment #11) > > field generic param type change > fixed Great news! Is there any dev build available to try this on?
no, not yet. There are dev builds of AspectJ but none of AJDT that includes that fixed AspectJ. When everything is addressed I'll look to create one.
> inner class added/removed fixed > class removed/added fixed Basically I've fixed everything from your list I could recreate. Waiting on some AJDT build process changes then we can create an AJDT dev build that includes the fixes.
I noticed a new drop on the AJDT dev update site and retested this bug on it. It works great on normal Java projects! However, our workspace also contains aspectj eclipse plug-in projects. Other projects that depend on these projects (both normal Java and other Eclipse plug-in projects) are not updated at all by incremental compilation (all scenarios fail). This bug is in both dev 20100715 and AJDT 2.1.0 release. It seems another kind of problem. Should I open a new bug on this? I also have test projects and reproduce scenarios.
(In reply to comment #15) > This bug is in both dev 20100715 and AJDT 2.1.0 release. It seems another kind > of problem. Should I open a new bug on this? I also have test projects and > reproduce scenarios. Yes, please raise a new bug report for this issue. It would be great if you could attach the failing projects.
(In reply to comment #16) > (In reply to comment #15) > > This bug is in both dev 20100715 and AJDT 2.1.0 release. It seems another kind > > of problem. Should I open a new bug on this? I also have test projects and > > reproduce scenarios. > > Yes, please raise a new bug report for this issue. It would be great if you > could attach the failing projects. I've opened bug 320331 with test projects and reproduce scenario. If additional information or testing is needed I'll be happy to help!
fixes are all released for this.
