Community
Participate
Working Groups
Build Identifier: AJDT 2.2.0 version dated 20120314 While building a maven project (that uses spring with aspectj weaving), I encounter the following problem. I'm using AJDT support from http://download.eclipse.org/tools/ajdt/37/dev/update with a freshly installed eclipse-indigo (and a recent m2e). java.lang.IllegalStateException at org.aspectj.weaver.ReferenceType.getDeclaredInterfaces(ReferenceType.java:627) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:548) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:399) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:430) at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:399) at org.aspectj.weaver.R ... ferencesUpdateListener newSubFormTablePreferencesUpdateListener() end public abstract class org.nuclos.client.common.AbstractDetailsSubFormController Reproducible: Always Steps to Reproduce: 1. I don't have a real example. But you could check out from git. Git URLs are git://repo.or.cz/nuclos.git or http://repo.or.cz/r/nuclos.git. Use the branch '3.3'. 2. Go a little back in the branch, e.g. 'git checkout 96c833d24e270119 '. Import the maven project into eclipse. 3. While eclipse is running, update to the tip, e.g. 'git checkout 3.3'. Use refresh in eclipse. 4. This might be a follow up of https://bugs.eclipse.org/bugs/show_bug.cgi?id=368018.
I have same configuration but without m2e: the problem arise as well. To get the exception is sufficient to modify any source java file.
I've tried a plain Eclipse installation (using the BIRT pre-packaged distribution: eclipse-reporting-indigo-SR2-linux-gtk-x86_64.tar.gz) on Ubuntu Linux 10.04 64 bit. I've ONLY installed: - EGit from the official Indigo repository (currently, 1.3.0) - AJDT 2.2.0 (from http://download.eclipse.org/tools/ajdt/37/dev/update) I get exact same error, every time and when I modify and save a Java source file. Is this release broken?
Dear Fabio, let me put it that way: If you use AJDT dev update site, you will suffer from this bug. But if you use AJDT normal update site, you suffer from https://bugs.eclipse.org/bugs/show_bug.cgi?id=368018 . YMMV, but if you use eclipse 3.6 (helios), you will run into problems as well. Using AspectJ from within eclipse is nothing for fainthearts...
(In reply to comment #3) [...] Oh my... This arise two questions to me. First: is there someone that is able to use a tool in such conditions for his/her work? Second: I tried the Springsource bundle (package springsource-tool-suite-2.9.1.RELEASE-e3.7.2-linux-gtk-x86_64) that has all plugins preconfigured (STS, AspectJ, etc.) and there is the same error... I have a magical old installation (Eclipse 3.7.1, AJDT 2.2.0.e37x-20111123-0900 with AspectJ 1.7.0.20111123094400) that works fine (actually perfectly), should I clone it and go that way? Anyway, thanks for you (moral) support...
I'm investigating this at the moment. To answer some questions: > First: is there someone that is able to use a tool in such conditions for his/her work? as only a couple of people are hitting it, it must be a characteristic of the projects you happen to working on. Once you have this characteristic the tool appears unusable, but this characteristic isn't common so doesn't affect that many users (I'm still discovering what this characteristic is). > Second: I tried the Springsource bundle (package springsource-tool-suite-2.9.1.RELEASE-e3.7.2-linux-gtk-x86_64) that has all plugins preconfigured (STS, AspectJ, etc.) and there is the same error... STS 2.9.1 includes the latest dev build of AJDT, I'd expect it to have the same problem. The fact that Fabio says "To get the exception is sufficient to modify any source java file." and Thomas says "While eclipse is running, update to the tip, e.g. 'git checkout 3.3'. Use refresh in eclipse." tells me it is an incremental compilation problem. It doesn't happen on full builds. So I have to look at what the difference is between Thomas' 3.3 version and the commit hash he gives me - that tells me what source file modifications trigger this incremental issue.
unfortunately it appears to be pages and pages of differences between the commit hash and the 3.3 branch.
think i've fixed it. Wasn't able to distill down a testcase due to the size of the git commit/branch differences, but I could recreate it before my change and now i can't. Should be in an AJDT dev build in a few hours.
(In reply to comment #7) > think i've fixed it. Wasn't able to distill down a testcase due to the size of > the git commit/branch differences, but I could recreate it before my change and > now i can't. Should be in an AJDT dev build in a few hours. Wow, fantastic! Sorry to be able to answer only now, maybe I have another datail that would have helped. I get this error also with Spring STS 2.8.0 (springsource-tool-suite-2.8.0.RELEASE-e3.7.1-linux-gtk-x86_64) BUT the error doesn't come out if I install the dev AJDT release 2.2.0.e37x-20111123-0900 (don't remember what is the exact version of AJDT bundled in STS 2.8.0 but when I checked it they were not very far from each other). Anyway, thank you for your support. Cheers, Fabio
Created attachment 213696 [details] Complete Eclipse error report I installed the latest release (ajdt-e37x-20120405-1700 from the zip archive) on top of Spring STS 2.9.1. Now compiling single source files does work. But when I do a checkout other branch with EGit I get this: org.aspectj.weaver.BCException: Unexpected problem processing class at org.aspectj.ajdt.internal.core.builder.AjState.recordClassFile(AjState.java:1500) at org.aspectj.ajdt.internal.core.builder.AjState.noteResult(AjState.java:1322) at org.aspectj.ajdt.internal.core.builder.AjBuildManager$3.acceptResult(AjBuildManager.java:1058) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:426) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:805) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:468) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1028) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:309) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:189) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:127) at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:91) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:257) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.aspectj.org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException org.aspectj.org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException at org.aspectj.org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372) at org.aspectj.org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:134) at org.aspectj.ajdt.internal.core.builder.AjState.recordClassFile(AjState.java:1492) at org.aspectj.ajdt.internal.core.builder.AjState.noteResult(AjState.java:1322) at org.aspectj.ajdt.internal.core.builder.AjBuildManager$3.acceptResult(AjBuildManager.java:1058) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:426) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:805) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:468) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1028) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:309) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:189) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:127) at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:91) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:257) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) I attached complete error report.
Still happens in ajdt-e37x-20120405-1700. I think it is due to inter-type declarations that are picked up by anonymous classes. Once I excluded anonymous classes from the match, it stopped happening.
@Fabio - the org.aspectj.weaver.BCException: Unexpected problem processing class at org.aspectj.ajdt.internal.core.builder.AjState.recordClassFile(AjState.java:1500) looks like a new issue. Are you able to tell me a git repo I can clone to recreate it? @Danil - when you say still happens I presume you mean the IllegalStateException and not the BCException Fabio mentions. Are you able to share with me a git repo that shows the problem? Without a test scenario it is tricky to tie down all reasons for this problem. (I'll try to play around with an ITD targetting an anon inner when I get a moment).
Yes, IllegalStateException. Unfortunately, it's a big corporate product so I can't share the repository. I can provide what the .aj file looks like.
@Danil In the last few builds I added a new IllegalStateException that should occur when things start to go wrong (as opposed to the existing IllegalStateException which is produced during a checking step too late in the process to help diagnose what went wrong earlier). Can you include the stacktrace you are seeing so we can see if it is the new one? I've tried playing around and I can't make it fail. It is probably a combination of generics involved around the inner type declaration. If you could let me know the declare parents you are using and the 'shape' of the target, that would help. Is it as simple as some generic type with an anonymous inner? public class A<T> { Runnable r = new Runnable() { public void run() {} }; } aspect X { declare parents: Runnable+ implements I; } interface I {} or something else?
Created attachment 213793 [details] Project with error I cannot share the original project (it's a corporate internal project). Anyway I did this to isolate the problem: 1) created a new empty Java project 2) copied into it the source file that originated the problem (as per the error log I previously attached, that reports a problem in my source class it.midhgard.oberon.gui.gestionecommessa.PanelCommessa$CommessaForm$3) 3) activated Aspect J on the project In this situation, doing a rebuild gives another problem on the same source file (it seems due to the fact that the source file has compilation errors - it lacks all the dependencies). I'm going to attach the complete error report for this. HTH
Created attachment 213794 [details] Error report for "project with error"
Anonymous Class (yes, parameterized) new SecurityTask<String>() { @Override public String execute() { --- Stack-Trace: java.lang.IllegalStateException at org.aspectj.weaver.ReferenceType.getDeclaredInterfaces(ReferenceType.java:643) at org.aspectj.weaver.bcel.BcelClassWeaver.checkForOverride(BcelClassWeaver.java:761) at org.aspectj.weaver.bcel.BcelClassWeaver.calculateAnyRequiredBridgeMethods(BcelClassWeaver.java:859) at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1699) at org.aspectj.weaver.bcel.BcelWeaver.weaveWithoutDump(BcelWeaver.java: ... bject;)V RETURN end public transient void warn(String, Object[]) end class org.slc.sli.api.security.oauth.AuthController$1 There are two errors, actually, differing only the last line: `end class org.slc.sli.api.security.oauth.AuthController$2`
@Fabio - thanks for the test project. I see it covers a ClassCastException which isnt the recordClassFile issue you most recently mentioned you were having. I've fixed the ClassCast but still wont be able to do much on the recordClassFile problem until I can recreate.
@Danil thanks for the updated stack trace. I'm trying to build out a test program from your sample, but so far it is just working fine: === class C { public void m() { new SecurityTask<String>() { @Override public String execute() { return "abc"; } }; } } class SecurityTask<T> implements I1 { public String execute() { return "abc"; } } aspect X{ declare parents: I1+ && !I1 implements I2; } interface I1 {} interface I2 {} ===
I am using Eclipse-STS 2.9.1 and I updated to the dev-build. When I look at installed features it says (under STS) AspectJ Development Tools 2.2.0.e37x-20120405-1700 Same version is listed everywhere I can find reference to AJDT, but it could be an artifact of installation/tooling. -- Full aspect (package name changed). If i remove && !org.random.api.util.SecurityUtil.SecurityTask+ error happens -- public aspect LoggerCarrierAspect { declare parents : (org.random.api..* && !java.lang.Enum+ && !org.random.api.util.SecurityUtil.SecurityTask+) implements LoggerCarrier; public void LoggerCarrier.debug(String msg) { LoggerFactory.getLogger(this.getClass()).debug(msg); } public void LoggerCarrier.info(String msg) { LoggerFactory.getLogger(this.getClass()).info(msg); } public void LoggerCarrier.warn(String msg) { LoggerFactory.getLogger(this.getClass()).warn(msg); } public void LoggerCarrier.debug(String msg, Object... params) { LoggerFactory.getLogger(this.getClass()).debug(msg, params); } public void LoggerCarrier.info(String msg, Object... params) { LoggerFactory.getLogger(this.getClass()).info(msg, params); } public void LoggerCarrier.warn(String msg, Object... params) { LoggerFactory.getLogger(this.getClass()).warn(msg, params); } public void LoggerCarrier.error(String msg, Throwable x) { LoggerFactory.getLogger(this.getClass()).error(msg, x); } public void LoggerCarrier.audit(SecurityEvent event) { LoggerFactory.getLogger("audit").info(event.toString()); } }
I took your aspect and played some more but I still can't get it to fail. It is likely to do with the target of declare, the shape of the type containing the anonymous inner type. Is it: class Foo { Object o = new SecurityTask<String>() {} } or class Foo<T> { Object o = new SecurityTask<String>() {} } or class Foo<T> { static class Inner { Object o = new SecurityTask<String>() {} } } or class Foo implements Bar<String> { public void m() { Object o = new SecurityTask<String>() {} } } or some other variation. Also, is it failing on full builds or incremental builds (or both)?
Only incremental builds. It's ok on full builds. The target is an inner class too. Full class below ---- public class SecurityUtil { private static final Authentication FULL_ACCESS_AUTH; public static final String SYSTEM_ENTITY = "system_entity"; private static ThreadLocal<Authentication> cachedAuth = new ThreadLocal<Authentication>(); static { XYZPrincipal system = new XYZPrincipal("SYSTEM"); system.setEntity(new MongoEntity(SYSTEM_ENTITY, new HashMap<String, Object>())); FULL_ACCESS_AUTH = new PreAuthenticatedAuthenticationToken(system, "API", Arrays.asList(Right.FULL_ACCESS)); } public static <T> T sudoRun(SecurityTask<T> task) { T toReturn = null; cachedAuth.set(SecurityContextHolder.getContext().getAuthentication()); try { SecurityContextHolder.getContext().setAuthentication(FULL_ACCESS_AUTH); toReturn = task.execute(); } finally { SecurityContextHolder.getContext().setAuthentication(cachedAuth.get()); } return toReturn; } public static interface SecurityTask<T> { public T execute(); } }
Maybe invocation will help too... SecurityUtil.sudoRun(new SecurityTask<String>() { @Override public String execute() { ... } });
Well, I'm not a AspectJ nor Eclipse developer. But for me it looks like that there are assumptions in the AspectJ compiler code that doesn't hold when doing a eclipse incremental build. The vital point might be that eclipse is able to 'incremental compile' most of a project even if a few classes have (syntax) errors. Maybe a structural change in the code base imposes (or breaks) a kind of dependency between (former) unrelated classes. The weaver should handle conditions more gracefully when it can't determine interfaces etc. A very simple method would be to requeue offending classes instead of bailing out. I found some useful information about eclipse incremental builds at http://www.eclipse.org/articles/Article-Builders/builders.html .
@Danil - thanks for that, I'll try out a testcase using those elements tomorrow. @Thomas I don't really see it as being about assumptions being made, if the compiler ever throws an exception then it is a bug and it needs a proper fix. Surfacing most likely because we moved from AspectJ 1.6.12 based on Eclipse 3.3 (from 4 years ago) to an eclipse 3.7. The compiler internals had moved around a lot in 4 years and our changes on top of that compiler needed to also be moved. If something new needs patching then unless it is obvious it tends to get discovered whilst the new code is being tested out in the wild (like in this scenario). (Which is what 1.7.0.M1 was for). The AspectJ situation is a bit more complex than a pure Java case because we aren't just talking about compilation we are talking about the subsequent weaving step too, and things like ITDs/declare parents introduce more dependencies than a simple java system would have. AspectJ incremental compilation is pretty robust now, the last remaining hole in the incremental story is that the state of the incremental compile is not persisted across workspace restarts (hence you need to full build whenever you restart eclipse). This is also caused by AspectJ being more complex than pure Java and the additional state beyond what Java needs to persist is rather complicated (and currently too messy). Bugs like this one (IllegalStateExceptions occurring) can be a pain when you hit them, but the fact that not many people are hitting them indicate to me it is a corner case and likely some bit of the compiler we haven't patched up yet - until I can recreate exactly the problem though, I can't work out how it is getting into the error state, but I'm trying. The IllegalStateExceptions that are included in the code are designed to catch these situations as early as we can. If we didn't throw them we'd perhaps limp along a bit further but no doubt eventually get into a more funky situation that would be impossible to diagnose. > The vital point might be that eclipse is able to 'incremental compile' most of > a project even if a few classes have (syntax) errors. Yes, so can AspectJ. More amazing than just compiling, AspectJ will weave into broken code if you really want it to. > Maybe a structural change in the code base imposes (or breaks) a kind > of dependency between (former) unrelated classes. The weaver should > handle conditions more gracefully when it can't determine interfaces > etc. All dependencies are tracked in a pretty reliable way. What differs on an incremental compile is where your dependencies come from. When compiling all source, your dependencies are represented as Source entities. When incrementally compiling some single file all your dependencies are represented as binary entities. This immediately means all your testcode for the full source compile scenarios isn't going to catch any issues there are with incremental compiles because it isn't testing the binary representations. Now Danil has mentioned is an incremental compile issue that is a big benefit to my investigations, it means I need to construct a certain kind of testcase as a straightforward 'compile all this stuff' wont find it. > A very simple method would be to requeue offending classes > instead of bailing out. To me that would be just hiding the real problem - that there is something wrong that needs properly fixing. It would start to give you (the few guys hitting the corner case) poor incremental compile times and you wouldn't know any different because it was covering up for an exception. I can turn around fixes very quickly if I can recreate the issue, but these days AspectJ doesn't have many bugs that just involve a couple of source files, it tends to be more complex and more subtle (like the ITD on anonymous inner types in an incremental compile thing I'm trying to address right now). The steps you gave me with the nuclos repo were invaluable, there is no way I'd have tracked things down so quickly without those steps. Just wish I could get those kinds of steps for every issue :)
@Danil - I tried again to recreate the problem for an hour or so using the snippets of code from this bugzilla, but no luck :( I've decided to add some additional debug logic to try and catch the problem earlier to discover what situation leads to it. If you are able to install the latest dev build I'd be interested to know how it affects you (let me know any exceptions that come out). The update site is: http://download.eclipse.org/tools/ajdt/37/dev/update
Created attachment 214169 [details] Complete Eclipse error report I tried on STS 2.9.1 the latest update from dev update site, and it still has an error when changing branch with EGit: org.aspectj.weaver.BCException at org.aspectj.ajdt.internal.core.builder.AjState.recordClassFile(AjState.java:1500) at org.aspectj.ajdt.internal.core.builder.AjState.noteResult(AjState.java:1322) at org.aspectj.ajdt.internal.core.builder.AjBuildManager$3.acceptResult(AjBuildManager.java:1058) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:426) I attached the complete error report. I'm sorry but I cannot find any suitable way to share a project with you that can reproduce the problem. If there's something I can do to provide further help, let me know. Cheers, Fabio
This bug is for the problem of IllegalStateException with getDeclaredInterfaces() - so I've just opened the new bug 377096 to cover the recordClassFile issue you have mentioned in comment 9 and comment 26.
Dear Andrew, don't get me wrong - I'm completely convinced that you are more in the aspectj and eclipse subject than I am. However, bailing out every time a problem occurs in the incremental build is a BIG useability problem at present: Every bail-out will trigger a (modal!) error dialog. You have to press 'Ok' to every single one of them. This is VERY boring. In our project, when the error hits me, I normally get 20 to 250 (!!!, no kidding) error dialogs. And getting them to disappear will keep me busy for up to 3 minutes! As a consequence in our project, we opt to bail out of this hell completely: We will change our code to not use AspectJ weaving any more...
Hi Thomas, > However, bailing out every time a problem occurs in the incremental build is a > BIG useability problem at present: Every bail-out will trigger a (modal!) error > dialog. You have to press 'Ok' to every single one of them. > > This is VERY boring. In our project, when the error hits me, I normally get 20 > to 250 (!!!, no kidding) error dialogs. And getting them to disappear will keep > me busy for up to 3 minutes! That does sound like something AJDT could easily improve - a 'dont tell me again' option on the first dialog. From the description here I didn't get the impression that you were getting quite so many popups when the situation was occurring. > As a consequence in our project, we opt to bail out of this hell completely: We > will change our code to not use AspectJ weaving any more... Sorry to hear that. I'm trying to fix these things as fast as they come in but given the complexity of the system these days and how far we've come, it tends to only be complex scenarios that trigger issues (I don't get all that many 3 line testcases that demonstrate failures). I'm sure for those hitting an issue it is infuriating so I try to stay on top of these things. Compilation problems like this get top prority. Each time you've been able to share with me the exact failing case (even when it is a bit of a complex config) I've been able to fix it very quickly. From what I see on this bug: - the original IllegalStateException is mostly addressed - the only remaining issue I'm aware of is around ITDs on anonymous inner types in some situation I'm not able to recreate. Haven't heard back yet whether the diagnostics in the most recent build have picked something up. - the situation with recordClassFile (now tracked under bug 377096) has apparently been addressed by some other recent changes - but I'll leave the diagnostics in to collect info on that problem when it occurs again. I know there are comments from Fabio and Danil on here but can I ask what problem are you still hitting Thomas?
Oh just one more thing. I did want to say I appreciate you following the dev builds of AJDT and helping me shake down AspectJ 1.7.0 support - sharing recreate instructions like "clone this, checkout that tag" is invaluable to me and far more useful than some of the bug reports I get.
With the newest dev build (2.2.0.e37x-20120418-1400), I don't get the errors anymore. Thank you for active support. :)
@Danil D'oh :) That is exactly what happened in bug 377096 - I add some diagnostics and the problem goes away ! Thanks for the feedback. I'll leave this bug open a little longer to see if anything else comes up, but as far as I'm aware everything in this bug is addressed right now.
