Community
Participate
Working Groups
Java source completion crashed on me in Eclipse 3.2M3 running on Windows 200SP4. This is different from bug 118667. Matt Chapman reported there that my stacktrace deserved a bug entry of its own. Here it is. After this crash, java completion remains half broken until I restart Eclipse. Here is my stacktrace: java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference at org.eclipse.jdt.internal.codeassist.CompletionEngine.findEnumConstant(CompletionEngine.java:1924) at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:741) at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:1667) at org.eclipse.jdt.internal.core.Openable.codeComplete(Openable.java:127) at org.eclipse.jdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:290) at org.eclipse.jdt.internal.core.CompilationUnit.codeComplete(CompilationUnit.java:283) at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.internalComputeCompletionProposals(JavaCompletionProposalComputer.java:211) at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.computeCompletionProposals(JavaCompletionProposalComputer.java:191) at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:278) at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:248) at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:158) at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:143) at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1566) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:447) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$15(CompletionProposalPopup.java:444) at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:379) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:373) at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1414) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor$AdaptedSourceViewer.doOperation(CompilationUnitEditor.java:204) at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80) at org.eclipse.jface.action.Action.runWithEvent(Action.java:996) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:182) at org.eclipse.ui.internal.handlers.LegacyHandlerWrapper.execute(LegacyHandlerWrapper.java:108) at org.eclipse.core.commands.Command.execute(Command.java:287) at org.eclipse.core.commands.ParameterizedCommand.execute(ParameterizedCommand.java:401) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:459) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:781) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:828) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:550) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:493) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:117) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:975) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:895) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:920) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:905) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:933) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:929) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1243) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3241) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3142) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3908) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1703) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2854) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1774) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1738) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:376) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:106) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:165) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:338) at org.eclipse.core.launcher.Main.basicRun(Main.java:282) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952)
I can reproduce the bug in I20051212-0010 with public class X { void foo(E e) { switch (e) { case E.AAAA: case AAA: break; } } } enum E { AAAA, AAAB } Do you reproduce the bug with a similar test case ?
(In reply to comment #1) > > Do you reproduce the bug with a similar test case ? > I tried your test case and I could crash the completion subsystem too. I first defined the enum, then the class X. When trying to complete after typeing "case A" on the line "case AAA:", I got the crash. Result: a dialog with the following: Content Assist: Disabling the "org.eclipse.jdt.ui.JavaNoTypeCompletionProposalComputer" (org.eclipse.jdt.ui.JavaNoTypeCompletionProposalComputer) extension to the "javaCompletionProposalComputer" extension point. Reason: The extension has thrown a runtime exception. This is also the header I get in the Error Log file before the stacktrace. Stack trace the same as I reported already.
We will improve the UI side: we should not disable the processor automatically but give users a hint how to disable it manually. They can then choose to do so themselves.
(In reply to comment #3) > We will improve the UI side: we should not disable the processor automatically > but give users a hint how to disable it manually. They can then choose to do so > themselves. Daniel, I don't understand the proposed improvement. Why would we want to disable the processors as a user? I want Java completion to work in all circumstances for a Java construct, whether it is Java 1.4 or Java 5. Could you elaborate? Ringo
Sure you want it to work 100% all times - no question. As you can see in this PR programming errors do happen ;-). Up to now the code assist UI side disables code assist processors that crash automatically or take up to much time to complete and only calls the remaining completion processors. That's why you have to restart to enable the Java completion processor again. In the future we will notify you about the "bad" processor and leave you the choice to disable it manually or continue - accepting that you might get the error dialog again later.
This is indeed an improvement over the current situation. However, who will be looking for the root cause of the bad completion processor? David Audel posted a reproducible case, so this shouldn't be too hard to nail down, right?
The root cause is this PR and is in JDT Core. I just added comment 3 FYI.
Daniel, now I'm really puzzled. How on earth will improving the UI side fix the ClassCastException I reported? If I understand correctly, the improvement to the UI side will give a user the option to either keep the faulty completion processor running or disable it when it crashes. Still, even if I have the option to let it running, I will encounter the crash again if I type code that resembles the reproducible case, no?
JDT Core == non-UI code JDT UI == UI code This PR is in JDT Core and is about the CCE and has nothing to do with the improvements on the UI side that I posted as additional info in comment 3. Comment 3 only tells what JDT UI will do on the UI side to ease the pain if bugs like this happen.
*** This bug has been marked as a duplicate of 127323 ***
