Community
Participate
Working Groups
I have just built a 4.16M3 config in E:/Tools/Eclipse/4.16M3. The Error Log contains an Internal Error as below: E:\Tools\Eclipse\4.13\plugins\org.eclipse.emf.ecore_2.19.0.v20190822-1451.jar does indeed exist, but as part of my 4.13 installation. Why is 4.16 even accessing it? May explain why everything is so slow if my 20 legacy installations are all searched. Maybe it is a genuine dependency of a probably closed project. If so wht is there no Problems View entry to show me what needs fixing. I note that my API baselines do have a 4.13 entry, but it is not the selected baseline, so it should not be accesssed. ----- Java Model Exception: Java Model Status [E:\Tools\Eclipse\4.13\plugins\org.eclipse.emf.ecore_2.19.0.v20190822-1451.jar is not on its project's build path] at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:583) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:256) at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:530) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:250) at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:530) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:250) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:596) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:326) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:312) at org.eclipse.jdt.internal.core.Openable.getBuffer(Openable.java:298) at org.eclipse.jdt.internal.core.AbstractClassFile.getBuffer(AbstractClassFile.java:221) at org.eclipse.jdt.internal.core.AbstractClassFile.getSource(AbstractClassFile.java:336) at org.eclipse.jdt.debug.ui.breakpoints.JavaBreakpointConditionEditor.setBreakpoint(JavaBreakpointConditionEditor.java:284) at org.eclipse.jdt.debug.ui.breakpoints.JavaBreakpointConditionEditor.setInput(JavaBreakpointConditionEditor.java:222) at org.eclipse.jdt.internal.debug.ui.breakpoints.CompositeBreakpointEditor.setInput(CompositeBreakpointEditor.java:140) at org.eclipse.jdt.internal.debug.ui.breakpoints.AbstractDetailPane.display(AbstractDetailPane.java:301) at org.eclipse.debug.internal.ui.views.variables.details.DetailPaneProxy.setupPane(DetailPaneProxy.java:228) at org.eclipse.debug.internal.ui.views.variables.details.DetailPaneProxy.display(DetailPaneProxy.java:127) at org.eclipse.debug.internal.ui.views.variables.VariablesView.refreshDetailPaneContents(VariablesView.java:1157) at org.eclipse.debug.internal.ui.views.variables.VariablesView$8.selectionChanged(VariablesView.java:1111) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:823) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.ui.internal.JFaceUtil.lambda$0(JFaceUtil.java:47) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:820) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1660) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:1084) at org.eclipse.debug.internal.ui.viewers.model.InternalTreeModelViewer.trySelection(InternalTreeModelViewer.java:1007) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.handleSelect(TreeModelContentProvider.java:1655) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1293) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1299) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateModel(TreeModelContentProvider.java:565) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:530) at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.modelChanged(TreeModelContentProvider.java:506) at org.eclipse.debug.internal.ui.viewers.provisional.AbstractModelProxy$1.run(AbstractModelProxy.java:92) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.debug.internal.ui.viewers.provisional.AbstractModelProxy.fireModelChanged(AbstractModelProxy.java:96) at org.eclipse.debug.internal.ui.viewers.update.BreakpointManagerProxy$1.runInUIThread(BreakpointManagerProxy.java:172) at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3897) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3527) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1049) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:658) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:557) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:154) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594) at org.eclipse.equinox.launcher.Main.run(Main.java:1447) at org.eclipse.equinox.launcher.Main.main(Main.java:1420)
Extracting some interesting bits from the st: Java Model Exception: Java Model Status [E:\Tools\Eclipse\4.13\plugins\org.eclipse.emf.ecore_2.19.0.v20190822-1451.jar is not on its project's build path] org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:583) ... org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:312) org.eclipse.jdt.internal.core.Openable.getBuffer(Openable.java:298) org.eclipse.jdt.internal.core.AbstractClassFile.getSource(AbstractClassFile.java:336) org.eclipse.jdt.debug.ui.breakpoints.JavaBreakpointConditionEditor.setBreakpoint(JavaBreakpointConditionEditor.java:284) org.eclipse.jdt.debug.ui.breakpoints.JavaBreakpointConditionEditor.setInput(JavaBreakpointConditionEditor.java:222) org.eclipse.jdt.internal.debug.ui.breakpoints.CompositeBreakpointEditor.setInput(CompositeBreakpointEditor.java:140) ... org.eclipse.debug.internal.ui.views.variables.VariablesView.refreshDetailPaneContents(VariablesView.java:1157) org.eclipse.debug.internal.ui.views.variables.VariablesView$8.selectionChanged(VariablesView.java:1111) ... org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.modelChanged(TreeModelContentProvider.java:506) ... Moving to JDT/Debug with a couple of questions: What project is used for resolving the input of JavaBreakpointConditionEditor? Is it OK, that refreshing VariablesView propagates into CompositeBreakpointEditor.setInput?
(In reply to Stephan Herrmann from comment #1) > > Moving to JDT/Debug with a couple of questions: > > What project is used for resolving the input of > JavaBreakpointConditionEditor? It is the Java Project associated with the Breakpoint. > > Is it OK, that refreshing VariablesView propagates into > CompositeBreakpointEditor.setInput? The stacktrace is surprising: org.eclipse.jdt.internal.debug.ui.breakpoints.AbstractDetailPane.display(AbstractDetailPane.java:301) at org.eclipse.debug.internal.ui.views.variables.details.DetailPaneProxy.setupPane(DetailPaneProxy.java:228) This should not happen, org.eclipse.debug.internal.ui.views.variables.details.AbstractDetailPane should be invoked if variables view was selected, if breakpoint was selected org.eclipse.jdt.internal.debug.ui.breakpoints.AbstractDetailPane should be invoked. Can't reproduce this stacktrace locally.
A couple of faint possibilities. The launcher has recently taken to updating *.launch files on disk even though no edit occurred. In the last week I have launched m2e to use the 4.13 target platform to resolve an Xtext regression. The PDE target editor is so determined to be useful it likes to burn my CPU time loading referenced target platform contents and when it's really 'clever' it even changes my active target platform. (I would dearly love to replace the PDE target editor by a boring validating XML editor.) Anyway, a conspiracy of PDE, launcher and m2e could account for the 4.13 activation from a stale memento.
(In reply to Sarika Sinha from comment #2) > (In reply to Stephan Herrmann from comment #1) > > > > Moving to JDT/Debug with a couple of questions: > > > > What project is used for resolving the input of > > JavaBreakpointConditionEditor? > > It is the Java Project associated with the Breakpoint. I wasn't aware that breakpoints are associated with a project :) After Ed mentioned closed projects I just confirmed that breakpoints disappear from the view when their project is closed. So maybe this is smth that Ed should observe: do you see any breakpoints in the Breakpoints view belonging to a closed project? Just guessing. OTOH, it sounds like Sarika already has a hot track: (In reply to Sarika Sinha from comment #2) > The stacktrace is surprising: > org.eclipse.jdt.internal.debug.ui.breakpoints.AbstractDetailPane. > display(AbstractDetailPane.java:301) > at > org.eclipse.debug.internal.ui.views.variables.details.DetailPaneProxy. > setupPane(DetailPaneProxy.java:228) > > This should not happen, ...
(In reply to Stephan Herrmann from comment #4) > After Ed mentioned closed projects I just confirmed that breakpoints > disappear from the view when their project is closed. > > So maybe this is smth that Ed should observe: do you see any breakpoints in > the Breakpoints view belonging to a closed project? As commented on Bug 560212: One of many anomalies I see with breakpoints is a confusion between when I have a breakpoint set in EMF as a plugin, then the same file as a project, then the file as a project with extra debug added, then back as a plugin again. Since I keep my workspaces from release to release, I often suddenly discover that some stale breakpoints come back to life.
(In reply to Ed Willink from comment #5) > the file as a project with extra debug added, then back as a plugin again. I find this usage cycle often breaks the incremental builder so that after closing a checked out EMF project, it is often necessary to restart Eclipse. Even if not necessary, it is a lot quicker than successive cleans to clear out the dross. The API builder is even worse for stale incremental state. I have one plugin that regularly reports 200 API errors after some editing/branch changing until explicitly cleaned.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
