Community
Participate
Working Groups
When creating a new connection and expanding the My Home Filter I get an AssertionFailedException. This is a regression from Bug 225911, as the assert statement was added with that patch. Stacktrace: org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.core.runtime.AssertionFailedException: null argument:no adapter found for element Pending...) at org.eclipse.swt.SWT.error(SWT.java:3766) at org.eclipse.swt.SWT.error(SWT.java:3684) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3750) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3375) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2375) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2339) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2205) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:478) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:473) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:379) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) 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.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) Caused by: org.eclipse.core.runtime.AssertionFailedException: null argument:no adapter found for element Pending... at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:84) at org.eclipse.rse.internal.ui.view.ElementComparer.hashCode(ElementComparer.java:60) at org.eclipse.jface.viewers.CustomHashtable.hashCode(CustomHashtable.java:266) at org.eclipse.jface.viewers.CustomHashtable.get(CustomHashtable.java:236) at org.eclipse.jface.viewers.StructuredViewer.findItems(StructuredViewer.java:770) at org.eclipse.jface.viewers.AbstractTreeViewer.internalFindItems(AbstractTreeViewer.java:168) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRemove(AbstractTreeViewer.java:1891) at org.eclipse.jface.viewers.AbstractTreeViewer$6.run(AbstractTreeViewer.java:2150) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1365) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:391) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1328) at org.eclipse.jface.viewers.AbstractTreeViewer.remove(AbstractTreeViewer.java:2148) at org.eclipse.jface.viewers.AbstractTreeViewer.remove(AbstractTreeViewer.java:2202) at org.eclipse.ui.progress.DeferredTreeContentManager$4.runInUIThread(DeferredTreeContentManager.java:399) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:130) ... 23 more -----------Enter bugs above this line----------- TM 3.0M6 Testing installation : eclipse-SDK-3.4M5 RSE install : Dev Driver java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
That's yours Dave, I think...
The adapter might actually be null due to the lazy adapter loading from bug 218304 ... if that's the case then the issue would only be reproducable once while the files.ui bundle is not yet loaded. After it is loaded, the issue should no longer appear. One can check whether files.ui is active as follows: Window > Show View > Other > PDE Runtime > Plugin Registry Filter active plugins only Filter name=org.eclipse.rse.files.ui On the other hand, Kevin Doyle says: I think the assert might just not be valid. I'm not sure but the Pending... node wouldn't have an ISystemViewElementAdapter, so it should be null.
I put the assertion in since I believed that the adapter would never be null. I've removed the assertion and have it now returning the former result.
Created attachment 97635 [details] Patch improving element comparison I took the opportunity to analyze the code in more depth, and found found it to be correct but with only three minor flaws: 1. While we adapted to ISystemViewElementAdapter for the hashCode(), we'd adapt to ISystemDragDropAdapter for the equals() in SystemRegistry. Now that should usually never be a problem, but it is inconsistent. 2. We only allow adaptable elements to be compared in the element map. Now newer Eclipse added IAdapterManager, to support registering adapters even for objects that are not IAdaptable themselves. I thought that we should start picking this up, although is nowhere used in RSE yet so registering adapters for non-IAdaptable objects will almost certainly not bring the expected results. 3. We'd have to retrieve the ISystemRegistry instance, do an instanceof check and a class cast -- just in order to call a method that could also be static and thus directly accessible. At the same time, I saw that SystemRegistry#isSameObjectByAbsoluteName() was badly inefficient: * it would ask for adapters even if the absolute name was already given * it would make wild String concatenation just to compare subsystems, even if the absolute names were already unequal * it would make string concatenation, although simple instance comparison of the subsystems would already suffice See attached patch with my fixes. The patch should not change semantic behavior in any way (except allowing non-IAdaptables to behave properly), but when testing I think that the SystemView already felt to be performing a bit better - but that was just a personal feeling and not actually measured. Patch is already committed: [228774] Improve ElementComparer Performance
The patch looks fine to me.
