Summary: | assertion failed when opening a class file not not the classpath | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Adam Kiezun <akiezun> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | dirk_baeumer | ||||
Version: | 3.1 | ||||||
Target Milestone: | 3.2 M6 | ||||||
Hardware: | PC | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Adam Kiezun
2005-10-28 12:22:42 EDT
Moving to JDT/Core. The interesting question here is why the file is provided as a class file by JDT/Core in the first place. As far as I know we only have support for compilation units not being on the build path. This works for me with I20051102-0010. Please reopen if you have more details. Created attachment 33438 [details]
project
reopening - I see the bug again on Build id: I20051215-1506
attached is the project.
after adding the project, select the file debug/graph.Graph.class in the package explorer.
I get 19 (!) error dialogs in a sequence and each has a stack trace similar to this:
org.eclipse.jdt.internal.core.Assert$AssertionFailedException: Assertion failed;
at org.eclipse.jdt.internal.core.Assert.isTrue(Assert.java:89)
at org.eclipse.jdt.internal.core.Assert.isTrue(Assert.java:76)
at org.eclipse.jdt.internal.core.BinaryType.<init>(BinaryType.java:51)
at org.eclipse.jdt.internal.core.ClassFile.getType(ClassFile.java:464)
at org.eclipse.jdt.ui.actions.FindAction.findType(FindAction.java:201)
at org.eclipse.jdt.ui.actions.FindAction.getTypeIfPossible(FindAction.java:135)
at org.eclipse.jdt.ui.actions.FindAction.getJavaElement(FindAction.java:150)
at org.eclipse.jdt.ui.actions.FindAction.canOperateOn(FindAction.java:101)
at org.eclipse.jdt.ui.actions.FindAction.selectionChanged(FindAction.java:257)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchSelectionChanged(SelectionDispatchAction.java:237)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.selectionChanged(SelectionDispatchAction.java:232)
at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:162)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:785)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:148)
at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160)
at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:1784)
at org.eclipse.jface.viewers.StructuredViewer.handleSelect(StructuredViewer.java:1027)
at org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(StructuredViewer.java:1053)
at org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(OpenStrategy.java:210)
at org.eclipse.jface.util.OpenStrategy.access$3(OpenStrategy.java:205)
at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:365)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:914)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3285)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2905)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1762)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1726)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:397)
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:109)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:379)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
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:585)
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)
reopening (In reply to comment #1) > The interesting question here is why the file is provided as > a class file by JDT/Core in the first place. As far as I know we only have > support for compilation units not being on the build path. .class file outside the classpath are also supported. Actually if we returned null for JavaCore.create(IResource) for a .class file outside the classpath, this would throw an exception in the class file editor. The problem here is not that the .class file is outside the classpath, but rather that it is not a valid .class file name (extra dot before the .class extension). Simple fix would be to remove Assert.isTrue(name.indexOf('.') == -1); as it looks like we behave correctly with such a .class file name. Removed assertion and added regression test ClassFileTests#testDotName() Verified for 3.2M6 using build I20060327-0010. |