Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 100753 - Last editor held by HintsUI.INSTANCE
Last editor held by HintsUI.INSTANCE
Product: java
Classification: Unclassified
Component: Hints
All All
: P2 (vote)
: 6.x
Assigned To: Miloslav Metelka
: 85312 102417 104549 105080 123660 123857 124715 (view as bug list)
Depends on:
Blocks: 123530 98405 105078 105079 121855 123003 123660
  Show dependency treegraph
Reported: 2007-04-12 10:34 UTC by _ rkubacki
Modified: 2008-03-10 15:48 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT

Patch adding "lastFocusedRemoved" property (10.26 KB, patch)
2007-10-21 23:48 UTC, Miloslav Metelka
Details | Diff
CompletionProvider NPE patch (975 bytes, text/plain)
2008-01-08 01:09 UTC, Shivanand Kini
EditorRegistry assertionerror patch (11.29 KB, text/plain)
2008-01-08 01:10 UTC, Shivanand Kini

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2007-04-12 10:34:38 UTC
similar to issue #100752. It is not nice if we have editors that are very
eager like XSD or some others in enterprise support.

Static reference from org.netbeans.modules.editor.hints.HintsUI.INSTANCE (from
class org.netbeans.modules.editor.hints.HintsUI) :
--> org.netbeans.modules.editor.hints.HintsUI@0x6d2f6d00 (40 bytes) (field comp:)
--> org.openide.text.QuietEditorPane@0x74734fa8 (451 bytes) (field parent:)
--> javax.swing.JViewport@0x749e7718 (351 bytes) (field parent:)
--> javax.swing.JScrollPane@0x749eb180 (369 bytes) (field parent:)
--> javax.swing.JPanel@0x749e7580 (320 bytes) (field parent:)
(415 bytes)
Comment 1 Jan Lahoda 2007-04-20 09:43:02 UTC
Should be fixed altogether with issue #100752.
Comment 2 _ rkubacki 2007-04-26 21:03:52 UTC
*** Issue 102417 has been marked as a duplicate of this issue. ***
Comment 3 Jan Lahoda 2007-04-26 21:27:40 UTC
See #102417.
Comment 4 Petr Hrebejk 2007-04-27 17:57:31 UTC
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.

Comment 5 Samaresh Panda 2007-04-27 18:28:36 UTC
Sorry I didnt realize that you made it P3 again.
Comment 6 Petr Hrebejk 2007-04-27 18:39:08 UTC
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.

Comment 7 Jan Lahoda 2007-05-25 17:23:01 UTC
*** Issue 104549 has been marked as a duplicate of this issue. ***
Comment 8 Jan Lahoda 2007-06-04 17:31:10 UTC
*** Issue 105080 has been marked as a duplicate of this issue. ***
Comment 9 Shivanand Kini 2007-07-31 19:23:48 UTC
can we have fix for this before the beta?
Comment 10 Jan Lahoda 2007-08-06 12:24:23 UTC
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.
Comment 11 Samaresh Panda 2007-09-14 23:00:32 UTC
Can someone look at this?
Comment 12 Jan Lahoda 2007-09-16 14:48:40 UTC
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.
Comment 13 Jan Lahoda 2007-10-12 19:49:44 UTC
*** Issue 85312 has been marked as a duplicate of this issue. ***
Comment 14 Shivanand Kini 2007-10-16 18:33:31 UTC
Mila, please can we have a fix for this at the earliest?
Comment 15 Miloslav Metelka 2007-10-17 14:46:05 UTC
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.
Comment 16 Miloslav Metelka 2007-10-21 23:46:45 UTC
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.
Comment 17 Miloslav Metelka 2007-10-21 23:48:05 UTC
Created attachment 51384 [details]
Patch adding "lastFocusedRemoved" property
Comment 18 Quy Nguyen 2007-12-07 22:41:16 UTC
*** Issue 123660 has been marked as a duplicate of this issue. ***
Comment 19 Quy Nguyen 2007-12-07 22:41:31 UTC
*** Issue 123660 has been marked as a duplicate of this issue. ***
Comment 20 Jan Lahoda 2007-12-07 23:01:45 UTC
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.
Comment 21 Jan Lahoda 2007-12-09 20:15:40 UTC
*** Issue 105080 has been marked as a duplicate of this issue. ***
Comment 22 Jan Lahoda 2007-12-12 22:26:36 UTC
*** Issue 123857 has been marked as a duplicate of this issue. ***
Comment 23 Jan Lahoda 2008-01-04 16:29:07 UTC
*** Issue 124715 has been marked as a duplicate of this issue. ***
Comment 24 Shivanand Kini 2008-01-08 01:09:04 UTC
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.

Comment 25 Shivanand Kini 2008-01-08 01:09:49 UTC
Created attachment 54786 [details]
CompletionProvider NPE patch
Comment 26 Shivanand Kini 2008-01-08 01:10:13 UTC
Created attachment 54787 [details]
EditorRegistry assertionerror patch
Comment 27 Miloslav Metelka 2008-01-08 09:29:23 UTC
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.
Comment 28 Miloslav Metelka 2008-01-09 17:08:39 UTC
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/;
/cvs/editor/src/org/netbeans/modules/editor/,v  <--
new revision: 1.129; previous revision: 1.128
Checking in nbproject/project.xml;
/cvs/editor/nbproject/project.xml,v  <--  project.xml
new revision: 1.39; previous revision: 1.38
Checking in lib2/src/org/netbeans/api/editor/;
/cvs/editor/lib2/src/org/netbeans/api/editor/,v  <--
new revision: 1.4; previous revision: 1.3
Checking in lib2/src/org/netbeans/modules/editor/lib2/;
/cvs/editor/lib2/src/org/netbeans/modules/editor/lib2/,v  <--
new revision: 1.3; previous revision: 1.2
Checking in completion/src/org/netbeans/modules/editor/completion/;
/cvs/editor/completion/src/org/netbeans/modules/editor/completion/,v  <--
new revision: 1.91; previous revision: 1.90
Comment 29 Jaroslav Tulach 2008-01-09 20:09:17 UTC
Should not you write a test for this new very important behavior (whatever it is)?
Comment 30 Miloslav Metelka 2008-01-10 15:37:35 UTC
Right, I have added a test.

Checking in;
/cvs/editor/lib2/test/unit/src/org/netbeans/api/editor/,v  <--
new revision: 1.3; previous revision: 1.2
Comment 31 Quy Nguyen 2008-01-18 02:40:23 UTC
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.
Comment 32 Quy Nguyen 2008-03-07 00:50:42 UTC
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:

private static final org.netbeans.napi.gsfret.source.Source$EditorRegistryListener
Comment 33 Jaroslav Tulach 2008-03-10 15:48:04 UTC
I believe the last report is in fact caused by issue 129435

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo