Community
Participate
Working Groups
Build 20020326 The implementation of DocumentAdapter#close() prevents it from ever being closed (logic on null check against fDocument is wrong). Therefore, such buffers will leak in the JavaModel buffer manager.
Another problem behind this one is that #close is nullifying the listeners slot, and therefore IBuffer#removeBufferChangedListener cannot be called from thereon by the infrastructure when noticing the buffer being closed (this is a recent change post 20020326). java.lang.NullPointerException at org.eclipse.jdt.internal.ui.javaeditor.DocumentAdapter.removeBufferChangedListen er(DocumentAdapter.java:167) at org.eclipse.jdt.internal.core.Openable.closeBuffer(Openable.java:83) at org.eclipse.jdt.internal.core.Openable.closing(Openable.java:91) at org.eclipse.jdt.internal.core.JavaElement.close(JavaElement.java:106) at org.eclipse.jdt.internal.core.WorkingCopy.destroy (WorkingCopy.java:80) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.disposeEl ementInfo(CompilationUnitDocumentProvider.java:224) at org.eclipse.ui.texteditor.AbstractDocumentProvider.disconnect (AbstractDocumentProvider.java:273) at org.eclipse.ui.texteditor.AbstractTextEditor.dispose (AbstractTextEditor.java:1422) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.dispose (CompilationUnitEditor.java:933) at org.eclipse.ui.internal.WorkbenchPage.closeEditor (WorkbenchPage.java:422) at org.eclipse.ui.internal.EditorPane.doHide(EditorPane.java:76) at org.eclipse.ui.internal.EditorWorkbook$1.itemClosed (EditorWorkbook.java:122) at org.eclipse.swt.custom.CTabFolder.closeNotify(CTabFolder.java:303) at org.eclipse.swt.custom.CTabFolder.access$12(CTabFolder.java:293) at org.eclipse.swt.custom.CTabFolder$4.handleEvent(CTabFolder.java:424) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:75) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:637) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1420) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1208) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:722) at org.eclipse.ui.internal.Workbench.run(Workbench.java:705) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:777) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:319) at EclipseRuntimeLauncher.main(EclipseRuntimeLauncher.java:14) Unhandled exception caught in event loop. Reason: java.lang.NullPointerException
Fixed bug in implementation of close. Don't set listeners list to null in order to allow post-close listener operations. This is different from the java doc of close. Pls specify which methods can be called after close and what happens if one of the other methods is called. Moving to JDT core.
Running with "closable" buffers, I see the following problem when hovering over identifiers. The problem seems that the buffer has been closed, but the calling code does not check this. Rolling back the change for stability. Thread [main] (Suspended (exception java.lang.NullPointerException)) org.eclipse.jdt.internal.ui.javaeditor.DocumentAdapter.getLength() line: 233 org.eclipse.jdt.internal.core.WorkingCopy (org.eclipse.jdt.internal.core.Openable).codeSelect (org.eclipse.jdt.internal.compiler.env.ICompilationUnit, int, int, org.eclipse.jdt.internal.codeassist.ISelectionRequestor) line: 132 org.eclipse.jdt.internal.core.WorkingCopy (org.eclipse.jdt.internal.core.Openable).codeSelect (org.eclipse.jdt.internal.compiler.env.ICompilationUnit, int, int) line: 121 org.eclipse.jdt.internal.core.WorkingCopy (org.eclipse.jdt.internal.core.CompilationUnit).codeSelect(int, int) line: 100 org.eclipse.jdt.internal.ui.text.java.hover.JavaTypeHover.getHoverInfo (org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion) line: 93 org.eclipse.jdt.internal.ui.text.java.hover.JavaTextHover.getHoverInfo (org.eclipse.jface.text.ITextViewer, org.eclipse.jface.text.IRegion) line: 300 org.eclipse.jface.text.TextViewerHoverManager.computeInformation() line: 56 org.eclipse.jface.text.TextViewerHoverManager (org.eclipse.jface.text.AbstractInformationControlManager).showInformation() line: 536 org.eclipse.jface.text.AbstractHoverInformationControlManager$MouseTrack er.mouseHover(org.eclipse.swt.events.MouseEvent) line: 233 org.eclipse.swt.widgets.TypedListener.handleEvent (org.eclipse.swt.widgets.Event) line: 207 org.eclipse.swt.widgets.EventTable.sendEvent (org.eclipse.swt.widgets.Event) line: 75 org.eclipse.swt.custom.StyledText (org.eclipse.swt.widgets.Widget).notifyListeners(int, org.eclipse.swt.widgets.Event) line: 637 org.eclipse.swt.widgets.Display.runDeferredEvents() line: 1420 org.eclipse.swt.widgets.Display.readAndDispatch() line: 1208 org.eclipse.ui.internal.Workbench.runEventLoop() line: 755 org.eclipse.ui.internal.Workbench.run(java.lang.Object) line: 738 org.eclipse.core.internal.boot.InternalBootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[]) line: 777 org.eclipse.core.boot.BootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[]) line: 319 EclipseRuntimeLauncher.main(java.lang.String[]) line: 14
How did this buffer get closed in the first place ?
Kai, do you know why the buffer was closed?
Didn't check.
Do you plan to check?
Moving to JDT/UI to get attention.
Closing is done by the buffer manager of JCore.
If the buffer doesn't have unsaved changes, then it is legite for it to be closed by the buffer management (when needing space). Note that we found an inconsistency in the buffer management which could have lead to requesting twice to close the same buffer. Please double check your behavior with integration build 20020416 where we will have released this fix.
We actually found an inconsistency in our buffer manager (could keep the buffer in, though it wanted to close it). From thereon, it would not have reopened the buffer, but rather reused closed one thus factory did not get involved. Fixed
