Bug 100753

Should be fixed altogether with issue #100752.

*** Issue 102417 has been marked as a duplicate of this issue. ***

See #102417.

I sotrongly disagree that this is a P1 J1 stopper bug. If you have editor which
consumes such a large amount of memory that it hurts the ide ix it on the proper
place e.g. XSD.

Sorry I didnt realize that you made it P3 again.

Just for record. We will not fix this for M9. Reasons:

1) The fix might be risky
2) Memory consumption scales well from our point of view. No matter how many
files  user opens/closes just one is held.
3) Only happens when the user has all files closed.
4) If we fix this reference there still be several others. So there is no
guarantee that the fix will help
5) It is not true that this issue blocks #98405. Even if we fix it the user will
not be able to open more than one bigger XSD file or do any other action in the
IDE e.g. open a project without potential getting OOME. So these bugs are unrelated.
6) Look at opening and closing other filetypes it woks well.



 

*** Issue 104549 has been marked as a duplicate of this issue. ***

*** Issue 105080 has been marked as a duplicate of this issue. ***

can we have fix for this before the beta?

Several things happened on this recently:
-Petr Nejedly fixed issue #104461 (which should ensure that components are correctly unregistered from the old
org.netbeans.editor.Registry even if the components are multiviews).
-I have rewritten editor/hints and java/source to use EditorRegistry (which is a new API)

Unfortunately, when all components are closed, an event is fired from the EditorRegistry, and
EditorRegistry.lastFocusedComponent() still returns a component during processing of the event. So editor/hints and
java/source hold the component (because they do not know the component is already closed).

Possible solutions:
-EditorRegistry could ensure that when all components are closed, an event is fired in such a way that ER.lFC() would
return null during processing the event. I think that this would be the best option (it would be easy to write the
listeners correctly). Mila promised he will try to modify EditorRegistry accordingly.
-the clients could be rewritten to ER.focusedComponent() (which returns null during the last event processing), but I am
not sure about what would be the impact of such a change (both performance and behavior).
-rewrite the clients not to hold the component hard - might be relatively simple for editor/hints, but probably very
difficult for java/source.

Can someone look at this?

Sorry, but I do not think this qualifies as a P2. As I wrote above, Mila will try to modify the EditorRegistry in such a
way that "ER.lFC() == null" during the event thrown after closing the last editor pane, but I guess he unfortunately did
not have spare cycles to actually do it yet.

*** Issue 85312 has been marked as a duplicate of this issue. ***

Mila, please can we have a fix for this at the earliest?

Ok, I'll do it.
But I see no straightforward solution for checking when component is "closed" in the EditorRegistry. As a first attempt
I would use AncestorListener.ancestorRemoved() but since this one is also fired when maximizing windows in our winsys I
would combine it with a 2000ms timer started in ancestorRemoved() and if the component does not get re-added in 2000ms
then I will fire the EditorRegistry listeners.
If anyone know about better solution please speak up.

Honzo, I'm not sure whether you've meant originally that ("focusLost", null, null) would be fired (once there are no
longer any registered components) or anything else??
For me it seemed cleaner to add an extra "lastFocusedRemoved" property that gets fired when last-focused-component gets
removed from component hierarchy for >2000ms. So ("lastFocusedRemoved", removed-last-focused-component,
current-focused-component) would get fired and you may check (evt.getNewValue() == null) if there are no more registered
components. Let me know if you're ok with this or not. Thanks.

Created attachment 51384 [details]
Patch adding "lastFocusedRemoved" property

*** Issue 123660 has been marked as a duplicate of this issue. ***

*** Issue 123660 has been marked as a duplicate of this issue. ***

For hints and java/source, it should be enough if any event would come (hints and java/source do not check touch the
event at all), and EditorRegistry.lastFocusedComponent() would return null at that time. It should clear the references.

*** Issue 105080 has been marked as a duplicate of this issue. ***

*** Issue 123857 has been marked as a duplicate of this issue. ***

*** Issue 124715 has been marked as a duplicate of this issue. ***

I was trying to test this with the wsdleditor. I got a NPE and a AssertionError.

To reproduce NPE:
1. Open a wsdl document in wsdl editor, after the given (initial) patch is applied.
2. NPE is thrown from CompletionProvider


To reproduce Assertion Error:
1.Once NPE is fixed. Open wsdl document.
2.Go to source view.
3.AssertionError is thrown.


I tried to patch it. But my knowledge of the editor code is zero.
I will attach the patch. Please review and make appropriate changes.

Unfortunately, I did not backup the log files. Let me know if you need it.

Created attachment 54786 [details]
CompletionProvider NPE patch

Created attachment 54787 [details]
EditorRegistry assertionerror patch

Thanks for the patch improvement. I'm still working on the final patch since the original thought with the ancestor does
not work well for NB tabbed container that does add/removeNotify() for all the (editor) tabs except the one that is
focused. So the solution must be more complex because the unfocused editor panes still need to be members of the
EditorRegistry (due to proper function of WordMatch etc.). I expect to integrate the final fix during this week.

I have a final fix. I have also patched the CompletionImpl.

Added API keyword since new property EditorRegistry.LAST_FOCUSED_REMOVED_PROPERTY was added.
Since clients like java do not check for the property name specifically (they just recall ER.lastFocusedComponent() upon
propertyChange()) there should be no further changes of clients necessary.

Checking in src/org/netbeans/modules/editor/EditorModule.java;
/cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v  <--  EditorModule.java
new revision: 1.129; previous revision: 1.128
done
Checking in nbproject/project.xml;
/cvs/editor/nbproject/project.xml,v  <--  project.xml
new revision: 1.39; previous revision: 1.38
done
Checking in lib2/src/org/netbeans/api/editor/EditorRegistry.java;
/cvs/editor/lib2/src/org/netbeans/api/editor/EditorRegistry.java,v  <--  EditorRegistry.java
new revision: 1.4; previous revision: 1.3
done
Checking in lib2/src/org/netbeans/modules/editor/lib2/EditorApiPackageAccessor.java;
/cvs/editor/lib2/src/org/netbeans/modules/editor/lib2/EditorApiPackageAccessor.java,v  <--  EditorApiPackageAccessor.java
new revision: 1.3; previous revision: 1.2
done
Checking in completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java;
/cvs/editor/completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java,v  <--  CompletionImpl.java
new revision: 1.91; previous revision: 1.90

Should not you write a test for this new very important behavior (whatever it is)?

Right, I have added a test.

Checking in EditorRegistryTest.java;
/cvs/editor/lib2/test/unit/src/org/netbeans/api/editor/EditorRegistryTest.java,v  <--  EditorRegistryTest.java
new revision: 1.3; previous revision: 1.2

This fix does not seem to fix one of the issues marked as a duplicate (Issue 123857).  When testing with visual web, the
TopComponent for the designer is still held from the JavaSource.binding field until another editor is opened.

The JavaSource.editorRegistryListener field is still holding onto the last editor in the case of visualweb.  To reproduce:
1) Create a web project w/ visual web framework
2) Switch Page1 to JSP tab
3) Close page and project.

The TopComponent for the designer is still held in memory, shown below:

org.netbeans.modules.visualweb.designer.jsf.ui.JsfTopComponent[Visual
Design,0,0,1014x958,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=448,maximumSize=,minimumSize=,preferredSize=]:
private static final org.netbeans.napi.gsfret.source.Source$EditorRegistryListener
org.netbeans.napi.gsfret.source.Source.editorRegistryListener->
org.netbeans.napi.gsfret.source.Source$EditorRegistryListener@1412262-lastEditor->
org.openide.text.QuietEditorPane@1d65df9-ui->
org.netbeans.editor.BaseTextUI@fa24f9-editorUI->
org.netbeans.modules.editor.NbEditorUI@9a442-toolBarComponent->
org.netbeans.modules.editor.NbEditorToolBar@4f9c0c-component->
[Ljava.awt.Component;@175873c-[10]->
org.openide.awt.Actions$ToolbarButton@1c36cea-listenerList->
javax.swing.event.EventListenerList@186f93c-listenerList->
[Ljava.lang.Object;@19d374c-[3]->
org.openide.util.actions.NodeAction$DelegateAction@10d669a-result->
org.openide.util.lookup.ProxyLookup$R@939432-data->
org.openide.util.lookup.ProxyLookup$SingleInternalData@1e6c1dd-lookups->
[Lorg.openide.util.Lookup;@1fc5167-[0]->
org.openide.windows.DefaultTopComponentLookup@13ea6bf-tc->
org.netbeans.modules.visualweb.project.jsfloader.JsfJspEditorSupport$JspEditorTopComponent@934cf4-parent->
javax.swing.JPanel@8165b3-component->
[Ljava.awt.Component;@e79817-[0]->
org.netbeans.modules.visualweb.designer.jsf.ui.JsfTopComponent@c64a78

I believe the last report is in fact caused by issue 129435