Community
Participate
Working Groups
When using the Java Perspective for refactoring, it is easily possible to cause the tree to display erroneous names. When a move of a class from one area to another occurs (most easily seen when deleting directories, or moving the second to last child node), the nodes get messed up, and duplicate names are displayed. A refresh does not resolve the misnaming - only a restart of the app will. When selecting a node, the proper name is displayed in the bottom left corner, so the tree knows the proper name - it's just the display that's messed up. This is most pronounced in 3.0M8.
Kirk, what do you mean with when a move of a class from one area to another occures. Are you moving a class from one package to another ? Furthermore classes are not contained in directories. What kind of directories are you deleting ?
We have been doing some major code restructuring which involved moving classes from one package to another (eg: com.acme.* -> org.os.*), moving directory contents (eg: bg/docs/props/*.properties -> plugins/bg/props/*), etc in preparation to moving our project from closed to open source. All of this movement is within the Java perspective's Package Explorer using the refactor menu selection. The tree control keeps getting lost during the movement of one or more elements, and the only way to repair it is to restart Eclipse. By lost I mean that the Package Explorer UI will show the same node name multiple times for something that was moved, eg: A package containing several java files core/utils/DateFormatComparator.java DateFormatUtils.java ... XMLFactory.java XMLHelper.java after moving several classes from the middle of the list to other packages one at a time, may end up with several files with the same name (e.g.: XMLHelper.java). However, selecting the tree node with the mouse will correctly identify the node name in the bottom left status bar. Hence, the tree nodes know their proper name, but the renderer has become out of sync with its data model. Please note that this doesn't happen -every- time, but it does happen over time. It is particularly noticeable when the item being refactered is referenced by lots of classes (>5).
I tested several moves but wasn't able to reproduce the bug. Kirk, two questions: - which concrete build are you using - do you have anything in the log. You can find the log in the .metadata directory The fact that the element gets rendered correctly in the status line indicats that the delta got processed and the viewer updated, but the tree items aren't rendered correctly. Rendering of the items is done by JFace.
Here's an exception that may indicate the issue, and I'm running the release version of 3.0M8: !SESSION Apr 30, 2004 14:07:18.890 --------------------------------------------- java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US !ENTRY org.eclipse.ui 4 4 Apr 30, 2004 14:07:18.890 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 Apr 30, 2004 14:07:18.890 !MESSAGE java.lang.NullPointerException !STACK 0 java.lang.NullPointerException at org.eclipse.ui.internal.progress.JobInfo.getCondensedDisplayString(JobInfo.java:289) at org.eclipse.ui.internal.progress.ProgressViewerLabelProvider.getText(ProgressViewerLabelProvider.java:29) at org.eclipse.ui.internal.progress.ProgressViewer$2.paintControl(ProgressViewer.java:179) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:82) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:769) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:793) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:778) at org.eclipse.swt.widgets.Composite.WM_PAINT(Composite.java:781) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2994) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3146) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1450) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2254) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1562) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1536) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:257) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:90) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:277) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:239) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:117) 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.basicRun(Main.java:267) at org.eclipse.core.launcher.Main.run(Main.java:692) at org.eclipse.core.launcher.Main.main(Main.java:676) Also, I just got it to happen during an add of a new abstract class. Unfortunately, there is not exception with the current timestamp, but this one is from earlier today: !SESSION May 07, 2004 15:12:40.718 --------------------------------------------- java.version=1.4.2_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US !ENTRY org.eclipse.ui 4 4 May 07, 2004 15:12:40.718 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 May 07, 2004 15:12:40.765 !MESSAGE Assertion failed: !STACK 0 org.eclipse.jface.text.Assert$AssertionFailedException: Assertion failed: at org.eclipse.jface.text.Assert.isTrue(Assert.java:175) at org.eclipse.jface.text.Assert.isTrue(Assert.java:160) at org.eclipse.jface.text.source.AnnotationModel.disconnect(AnnotationModel.java:315) at org.eclipse.jface.text.link.LinkedUIControl.leave(LinkedUIControl.java:996) at org.eclipse.jface.text.link.LinkedUIControl$LinkedUICloser.shellDeactivated(LinkedUIControl.java:312) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:167) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:769) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:793) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:774) at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE(Decorations.java:1482) at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:1325) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2943) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1439) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3146) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:1838) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2250) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1562) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1536) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:257) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:90) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:277) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:239) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:117) 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.basicRun(Main.java:267) at org.eclipse.core.launcher.Main.run(Main.java:692) at org.eclipse.core.launcher.Main.main(Main.java:676)
Kirk, both exceptions aren't releated to the code that updates the packages explorer. We fixed one bug (see 61270) that resulted in an incorrect delta when moving folders/packages. However that fact that the status line is rendered correctly somehow indicates a JFace problem. Moving to Platform/UI for comments.
Bug 55576 describes the problem with the incorrect updates. Can you tell me which build this occured on so that I can see if this is the same problem?
I am running build 200403261517. Bug 61270 seems similar to this one, but not exact. However, it may be that the same code used to fix that one will fix this as well. Bug 55576 doesn't seem related to this at all. Here's a new exception recently generated during editing. Unfortunately, the problem occurred again yesterday, but there were no new exceptions thrown when it occurred. Once the first error happens in a particular package, any further operations in that package will continue to display more duplicate names in the list. Here's the exception. FYI, corvette is the name of a project that is in the workspace, but is currently in the closed state since I'm working on corvette2. !ENTRY org.eclipse.team.ui 4 0 May 10, 2004 09:09:32.52 !MESSAGE Resource /corvette is not open. !STACK 1 org.eclipse.core.internal.resources.ResourceException: Resource /corvette is not open. at org.eclipse.core.internal.resources.Project.checkAccessible(Project.java:117) at org.eclipse.core.internal.resources.Resource.findMarkers(Resource.java:773) at org.eclipse.team.internal.ui.synchronize.SynchronizeModelProvider.propagateProblemMarkers(SynchronizeModelProvider.java:461) at org.eclipse.team.internal.ui.synchronize.SynchronizeModelProvider.calculateProperties(SynchronizeModelProvider.java:446) at org.eclipse.team.internal.ui.synchronize.SynchronizeModelProvider.resourceChanged(SynchronizeModelProvider.java:579) at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:255) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:610) at org.eclipse.core.runtime.Platform.run(Platform.java:521) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:248) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:142) at org.eclipse.core.internal.events.AutoBuildJob.broadcastChanges(AutoBuildJob.java:71) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:138) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:168) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:62) !SUBENTRY 1 org.eclipse.core.resources 4 372 May 10, 2004 09:09:32.52 !MESSAGE Resource /corvette is not open.
The problem in your stack traceis an resource exception in marker updating and not the same problem as this. Please log another bug for this.
Need to ensure this problem is addressed for 3.0. Kirk, does your .log file contain any stack traces with stack frames from AbstractTreeViewer.doUpdateItem? Until recently, viewers would stop updating labels if there was an error when calling the label provider. If this occurred, there would be a corresponding entry in the log.
Nick which problem are you referring to? The one in the original report or the other one with the problems view. Marking as P2 to be sure it is addressed for 3.0.
Unfortunately, my log file doesn't contain any AbstractTreeViewer.doUpdateItem errors - just lots of the ResourceExceptions shown below, along with a couple of the jface assertion failures. It is wierd, when the problem occurs, I don't see any new exceptions at all... Is there a debug setting I should use that might help? I've updated to the May 14 integration build to see if that has already addressed the problem.
I was referring to the original problem of the tree viewer labels not updating.
Kirk, the changes I mentioned in comment #9 are in the I20040514 build. Please let us know whether you still see the problem. Sorry, there are no relevant extra debug options. If you still see the problem in SynchronizeModelProvider.propagateProblemMarkers, please file a separate bug report for it against Platform-Team.
Could you also run eclipse with -vm {pathToJRE}\bin\java This will give you a console window. It's possible that errors are getting logged to the console but not the .log file.
Leaving open for now. We believe this was due to an error in the decorator manager that has been fixed. Please let us know if you see this on M9.
Marking as a dup of Bug 55576 as I believe it was the same problem. *** This bug has been marked as a duplicate of 55576 ***
