Community
Participate
Working Groups
To recreate: - Check out the QuickFix project from ajdt.test project - Open TestAspect.java in the Java Editor (right click > open with > Java Editor) - Click on the lightbulb with the error marker (the same line as File f = new File("tmp"); - An Internal Error appear in the Error log with the following stack trace: java.lang.NullPointerException at org.eclipse.jdt.internal.ui.text.correction.UnresolvedElementsSubProcessor.getT ypeProposals(UnresolvedElementsSubProcessor.java:395) at org.eclipse.jdt.internal.ui.text.correction.QuickFixProcessor.process (QuickFixProcessor.java:270) at org.eclipse.jdt.internal.ui.text.correction.QuickFixProcessor.getCorrections (QuickFixProcessor.java:202) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectCorr ections(JavaCorrectionProcessor.java:240) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.processAnno tations(JavaCorrectionProcessor.java:208) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.computeComp letionProposals(JavaCorrectionProcessor.java:177) at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposal s(ContentAssistant.java:1472) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals (CompletionProposalPopup.java:242) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$7 (CompletionProposalPopup.java:238) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$1.run (CompletionProposalPopup.java:197) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals (CompletionProposalPopup.java:192) at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions (ContentAssistant.java:1320) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionAssistant.showPossibl eCompletions(JavaCorrectionAssistant.java:159) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewe r.doOperation(CompilationUnitEditor.java:184) at org.eclipse.jdt.internal.ui.javaeditor.JavaSelectAnnotationRulerAction.run (JavaSelectAnnotationRulerAction.java:78) at org.eclipse.ui.texteditor.AbstractRulerActionDelegate.run (AbstractRulerActionDelegate.java:99) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:276) at org.eclipse.ui.internal.PluginAction.run(PluginAction.java:238) at org.eclipse.ui.texteditor.AbstractTextEditor$11.triggerAction (AbstractTextEditor.java:2110) at org.eclipse.ui.texteditor.AbstractTextEditor$11.mouseUp (AbstractTextEditor.java:2117) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:136) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2772) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2431) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1377) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:254) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:183) at org.eclipse.core.launcher.Main.run(Main.java:644) at org.eclipse.core.launcher.Main.main(Main.java:628) Looking at the jdt code in UnresolvedElementsSubProcessor.java, at line 395, the parent field is null: ASTNode parent= selectedNode.getParent(); while (parent.getLength() == selectedNode.getLength()) { // line 395 parent= parent.getParent(); } There just needs to be a null check as there is above: ASTNode selectedNode= problem.getCoveringNode(context.getASTRoot()); if (selectedNode == null) { return; } int kind= SimilarElementsRequestor.ALL_TYPES; ASTNode parent= selectedNode.getParent(); while (parent.getLength() == selectedNode.getLength()) { parent= parent.getParent(); } should become: ASTNode selectedNode= problem.getCoveringNode(context.getASTRoot()); if (selectedNode == null) { return; } int kind= SimilarElementsRequestor.ALL_TYPES; ASTNode parent= selectedNode.getParent(); if (parent == null) { return; } while (parent.getLength() == selectedNode.getLength()) { parent= parent.getParent(); } This needs to be raised as a jdt bug, since we don't pass through any ajdt code in order to get here. Raising this bug against ajdt is just for tracking. (note this happens on 1.1.12, but also on the latest AJDT dev build).
The problem still exists with the latest dev build of AJDT 1.3.0 on Eclipse 3.1, although the stack trace is now slightly different: java.lang.NullPointerException at org.eclipse.jdt.internal.ui.text.correction.ASTResolving.internalGetPossibleTypeKinds(ASTResolving.java:700) at org.eclipse.jdt.internal.ui.text.correction.ASTResolving.getPossibleTypeKinds(ASTResolving.java:663) at org.eclipse.jdt.internal.ui.text.correction.UnresolvedElementsSubProcessor.evauateTypeKind(UnresolvedElementsSubProcessor.java:493) at org.eclipse.jdt.internal.ui.text.correction.UnresolvedElementsSubProcessor.getTypeProposals(UnresolvedElementsSubProcessor.java:506) at org.eclipse.jdt.internal.ui.text.correction.QuickFixProcessor.process(QuickFixProcessor.java:268) at org.eclipse.jdt.internal.ui.text.correction.QuickFixProcessor.getCorrections(QuickFixProcessor.java:213) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionCollector.safeRun(JavaCorrectionProcessor.java:310) at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.run(JavaCorrectionProcessor.java:275) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
still happens?
I have confirmed that this is still a bug. Actually, I think it is more pervasive that this bug report claims. When opening an AspectJ file in a Java editor, it seems that no automated text edit operations work (quickfixes, content assist, formatting, etc). This issue is with Working Copy owners. The JavaModelManager stores working copy information in a way that is associated with a compilation unit's WorkingCopyOwner. Unless otherwise requested, the WorkingCopyOwner is the DefaultWorkingCopyOwner. When an AJ file is opened in an AJ editor, two things happen: 1. the AJ compilation unit sets its working copy owner to be an AJ working copy owner 2. the AJ editor associates the AJ compilation unit's working copy owner with the Java Model Manager (and removes the original DefaultWorkingCopyOwner). When an AJ file is opened in a Java editor only step 1 happens. This causes all sorts of problems when trying to edit text using certain operations. In the method AspectJEditor.doSetInput(), the logic for overriding the working copy owner occurs. But, this version of the method is not called when the Aspect is opened in a CompilationUnitEditor (doSetInput() is overrided in AspectJEditor). I don't have a solution yet, but I am still thinking about it.
Created attachment 99631 [details] This patch ensures that no exceptions are thrown when content assist is requested on a *.aj file when opened in a Java editor.
After a little more investigation, my recommendation is to not provide a fix for this, but rather simply avoid raising the exception. The reason for this is that the Java Editor is outside the scope of the AJDT and we cannot expect that Aspect code will behave properly in a Java editor. I am attaching a patch that adds a check to see if the *.aj file is opened in a Java editor. If this is the case, then content assist requests are ignored (rather than raise an error). This should catch most cases.
A little overzealous with marking this as resolved and fixed. I am reverting back the old status and will set it as fixed when the change makes it into the codebase. I am also attaching an updated patch that is mostly the same except slightly better modularized and documented.
Created attachment 99857 [details] Remodularzied original patch.
patch committed. iplog. We aren't going to get JDT changes in the short term so let's be pragmatic - if we can't play nicely in the Java editor, let's not try. I would like to capture all these design choices we make in one place, somewhere in an AJDT readme or on the AJDT wiki. We'll make sure that is done for 1.5.3 final.
