This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 199416 - no nodes in lookup of multiview
Summary: no nodes in lookup of multiview
Alias: None
Product: platform
Classification: Unclassified
Component: Actions (show other bugs)
Version: 7.1
Hardware: All All
: P2 normal (vote)
Assignee: Jaroslav Tulach
Depends on:
Reported: 2011-06-15 08:23 UTC by Tomas Stupka
Modified: 2011-07-17 13:59 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

registerEditor & associateLookup (26.70 KB, patch)
2011-06-20 12:35 UTC, Jaroslav Tulach
Details | Diff
Simplified JavaDataObject (9.11 KB, patch)
2011-06-20 12:37 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Stupka 2011-06-15 08:23:31 UTC
- apply the patch in #196810
- run the ide, create a java file and invoke the ctx menu on that files editor tab -> some NodeAction-s aren't properly enabled/displayed in the context menu anymore - e.g. the Diff action (diff/o.n.m.diff.DiffAction) which is a NodeAction and relies on nodes being contained in the given context/lookup.
Comment 1 Jaroslav Tulach 2011-06-20 12:35:19 UTC
Created attachment 108988 [details]
registerEditor & associateLookup
Comment 2 Jaroslav Tulach 2011-06-20 12:37:12 UTC
Created attachment 108989 [details]
Simplified JavaDataObject
Comment 3 Tomas Stupka 2011-06-30 14:19:02 UTC
fixed in:
core-main #f1f4b9e9adf9
core-main #7f92b34a8213 

branch multiview-no-nodes-199416

thanks for the patch

will close after merge
Comment 4 Jesse Glick 2011-07-01 18:23:05 UTC
[JG01] Returning an int from associateLookup is perplexing to anyone reading the code, and offers no type safety. Suggest replacing this with an enum.

[JG02] MultiDOEditor.createCookie checks DataEditorSupport.class.isAssignableFrom(klass). Why? This means that if you say

class X extends DataEditorSupport {...}
X x = obj.getCookie(X.class);

you will get a CCE. Anyway all these checks seem to be too much work; should just check klass.isAssignableFrom(Class.forName("org.openide.text.SimpleES")). (Would be a bit easier if this class were made public and moved to a private package; then Class.forName("org.openide.text.SimpleES") here and in registerEditor could also be replaced by SimpleES.class.)
Comment 5 Quality Engineering 2011-07-02 14:08:00 UTC
Integrated into 'main-golden'
User: Tomas Stupka <>
Log: issue #199416 - no nodes in lookup of multiview
- registerEditor & associateLookup
Comment 6 Jaroslav Tulach 2011-07-12 14:36:07 UTC
Re. JG02: f0b4c1bc3c2f
Re. JG01: As a Kurt Gödel fan, I don't find anything wrong on integers. I prefer them to enum, they clearly indicate the values may grown in future.

However Jan Lahoda pointed out that the whole concept of associateLookup suffers from mutability (e.g. one can return ++counter; from in there). Jan suggested to pass this value to constructor. However I don't like that, as the value should be specified for a subclass, not per instance. However we could have

@interface DataObject.AssociateLookup {
  int version;

if you find the annotation approach better, I can use it. Possibly also replace registerEditor method with boolean registerEditor annotation attribute. If the annotation concept is too hairy, I prefer to keep f0b4c1bc3c2f state.
Comment 7 Jesse Glick 2011-07-12 14:49:07 UTC
I do not see any advantage to @DataObject.AssociateLookup. IMO annotations which change semantics (i.e. not just for analysis or documentation) should not be used for anything but creation of lazy proxies.
Comment 8 Quality Engineering 2011-07-17 13:59:58 UTC
Integrated into 'main-golden'
User: Jaroslav Tulach <>
Log: #199416: [JG02] - moving SimpleES into non-public package and making it public