Community
Participate
Working Groups
Build ID: I20090611-1540 Steps To Reproduce: Tried AJDT versions 2.0.1e35x-20090712-0900 and 2.0.0ex35x-20090634-1600. Ran the workspace with weaving disabled and enabled, no difference. Eclipse Weaving Service, Equinox Aspects, and the XRef tools are installed. Essentially, every time I press CTL-SPACE (and sometimes even when I don't, e.g. type 'System.' in an advice block), a dialog pops stating 'Problems During Content Assist - the org.eclipse.jdt.ui.JavaAllCompletionProposalComputer' from the 'org'eclipse'jdt.ui' plug-in did not complete normally'. It then says to disable some of the content assists. However, even after disabling them all except the core Java proposals, the dialog still pops. More information: eclipse.buildId=I20090611-1540 java.version=1.6.0_14 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -vm C:\dev\java\jdk1.6.0\jre\bin\java.dll Command-line arguments: -os win32 -ws win32 -arch x86_64 -vm C:\dev\java\jdk1.6.0\jre\bin\java.dll The (seemingly related) stacktrace is provided in the below. More information: at org.eclipse.ajdt.core.parserbridge.AJCompilationUnitProblemFinder.processAJ(AJCompilationUnitProblemFinder.java:296) at org.eclipse.ajdt.core.parserbridge.AJCompilationUnitProblemFinder.processAJ(AJCompilationUnitProblemFinder.java:185) at org.eclipse.ajdt.core.reconcile.AJReconcileWorkingCopyOperation.makeConsistent(AJReconcileWorkingCopyOperation.java:244) at org.eclipse.ajdt.core.reconcile.AJReconcileWorkingCopyOperation.executeOperation(AJReconcileWorkingCopyOperation.java:121) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788) at org.eclipse.ajdt.core.javaelements.AJCompilationUnit.reconcile(AJCompilationUnit.java:496) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206) Caused by: java.lang.ClassCastException: org.eclipse.jdt.internal.core.CompilationUnit cannot be cast to org.eclipse.ajdt.core.javaelements.AJCompilationUnit at org.eclipse.ajdt.core.codeconversion.ITDAwareNameEnvironment.find(ITDAwareNameEnvironment.java:84) at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:286) at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:45) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:127) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getType(PackageBinding.java:127) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.isViewedAsDeprecated(PackageBinding.java:211) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isViewedAsDeprecated(ReferenceBinding.java:1199) at org.eclipse.jdt.internal.compiler.ast.ASTNode.isTypeUseDeprecated(ASTNode.java:467) at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:150) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:201) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:179) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1165) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces(ClassScope.java:956) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1009) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectMemberTypes(ClassScope.java:833) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1016) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:299) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:190) at org.eclipse.ajdt.core.codeconversion.ITDAwareLookupEnvironment.completeTypeBindings(ITDAwareLookupEnvironment.java:52) at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:871) at org.eclipse.ajdt.core.parserbridge.AJCompilationUnitProblemFinder.processAJ(AJCompilationUnitProblemFinder.java:240)
I have not been able to run this with the weaving service disabled yet, but I have with the weaving service enabled. The block of code that causes the CCE from the stack trace you provide should only be reached if you are running with the weaving service disabled. Tonight, I will try running with the weaving service disabled and see if I can recreate the exception you are seeing. If yes, then there is an easy fix. If not, then there is something else going on that is specific to your project. I will create a new build for you that includes extra diagnostics that may help with tracking the problem you are seeing. ps- this appears to be an AJDT bug, so moving over to that project.
Could not reproduce this bug, so I added some diagnostics. When you notice this error happening, look at the error log, AJDT should be logging some information about what is happening just before the error occurs. A few more questions: 1. Are you using aspects in .java files? 2. Are you editing Aspects in a Java Editor?
ps- the dev build should be available in a few hours if all goes well with the build server.
New build in 3.5 stream is available.
(In reply to comment #2) > Could not reproduce this bug, so I added some diagnostics. > > When you notice this error happening, look at the error log, AJDT should be > logging some information about what is happening just before the error occurs. > > A few more questions: > > 1. Are you using aspects in .java files? > > 2. Are you editing Aspects in a Java Editor? > 1. No, all of the aspects are in .aj files. 2. The 'AspectJ/Java Editor' is set as the default handler for .aj files; I've made sure to try to explicitly choose that as well during troubleshooting efforts.
(In reply to comment #1) > I have not been able to run this with the weaving service disabled yet, but I > have with the weaving service enabled. > > The block of code that causes the CCE from the stack trace you provide should > only be reached if you are running with the weaving service disabled. > > Tonight, I will try running with the weaving service disabled and see if I can > recreate the exception you are seeing. If yes, then there is an easy fix. If > not, then there is something else going on that is specific to your project. I > will create a new build for you that includes extra diagnostics that may help > with tracking the problem you are seeing. > > ps- this appears to be an AJDT bug, so moving over to that project. > According to the 'JDT Weaving' preference dialog, it says "JDT Weaving is currently ENABLED" with, of course, the button option to disable weaving. Is there another way to ensure weaving is 'truly' enabled? I do know that, upon reinstalling the plugin (or passing the '-clean' option at startup), I notice the dialog asking "Should JDT Weaving be enabled?" popping repeatedly--but perhaps that's the desired behavior unless one selects the 'don't ask until next upgrade' option? I've not had time to investigate that further.
(In reply to comment #6) > According to the 'JDT Weaving' preference dialog, it says "JDT Weaving is > currently ENABLED" with, of course, the button option to disable weaving. Is > there another way to ensure weaving is 'truly' enabled? This is the best way to determine if weaving is enabled. This functionality was added through weaving, and so would be disabled if weaving were not enabled. > I do know that, upon reinstalling the plugin (or passing the '-clean' option at > startup), I notice the dialog asking "Should JDT Weaving be enabled?" popping > repeatedly--but perhaps that's the desired behavior unless one selects the > 'don't ask until next upgrade' option? I've not had time to investigate that > further. This is the expected behavior. The weaving state is stored in the configuration. So, when a new version of Equinox Aspects is in stalled, or the configuration is cleaned, the previous weaving state is forgotten and so you are asked again. Please let me know if you are able to capture any diagnostics with the new version from the dev update site.
I've installed the the 2.0.1.e35x-20090714-2000 builds of the tools in question. I've attached the workspace log file (workspace_metadata_log_1.log)--the bug report seems to repeat itself, but I left it all there except for snipping out the source code it spits out that was open when the crash occurs. Let me know if you need that--I will say it happens even on dead-simple aspects now. The workspace in question has just two projects: one called QModel (the Aspect project) and one called 'slumlord' which is a Java project. I notice this showing in the log now: !MESSAGE Bug 283468: Unexpected JavaModelException thrown on type =slumlord/src<com.pgac.slumlord.data{package-info.java[package-info. Weaving Service turned on: 'true' We use the 'package-info.java' style of package doc as opposed to package.html. We use IvyDE to retrieve deps for our projects, so I was able to delete the 'slumlord' project from the workspace and tried to edit the same aspect which was throwing the error--success, code completion worked as normal. The imports for the aspect in question were as follows: import com.pgac.slumlord.data.ChildEvent; import com.pgac.slumlord.data.ChildEventSupport; import com.pgac.slumlord.data.ChildListener; import com.pgac.slumlord.data.ChildListenerSupport; import com.pgac.slumlord.data.ChildEvent.ChildEventType; import com.pgac.general.core.model.Driver; So I then tried to re-import the 'slumlord' project back into the workspace; after rebuilding, the problem re-occurred. There are a number of 'package-info.java' files in the 'slumlord' project, but I only had to delete the one from 'com.pgac.slumlord.data' to get the error NOT to occur. I hope this proves enlightening--thanks for your quick attention and all your help! Let me know if there's any more information you need.
Created attachment 141684 [details] Log file from the workspace .metadata folder 1
This is very helpful. Thanks for being patient and trying out the dev build. I will ensure that the package-info.java files are properly handled and this should address your problem.
This bug has been fixed. The fix will be available in the next dev build of the 3.5 stream.
I had the same problem, yet after upgrading to AJDT dev builds (Version: 2.0.1.e35x-20090925-1300), it's fine.
