Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 49731 - Remove JMIElementCookie or do not extend Node.Cookie
Remove JMIElementCookie or do not extend Node.Cookie
Product: java
Classification: Unclassified
Component: Unsupported
All All
: P2 (vote)
: 4.x
Assigned To: Jan Pokorsky
Depends on: 49741
  Show dependency treegraph
Reported: 2004-09-30 13:00 UTC by Jesse Glick
Modified: 2007-09-26 09:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT

Arch document diff. (1.59 KB, text/plain)
2004-10-06 14:20 UTC, Martin Matula

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-09-30 13:00:43 UTC
To track last comments from issue #45361.
Comment 1 Jesse Glick 2004-09-30 13:03:19 UTC
So the current state is that there is in java/javacore

public interface JMIElementCookie extends Node.Cookie {
    Element getElement();

and in java, JavaSourceNodeFactory.CompatibleNode which has Javadoc
saying "supplies cookies to ensure proper functionality of code that
uses the old source hierarchy api" and

- extends FilterNode

- does not use any special Lookup

- overrides getCookie to return an org.openide.src.Element (which has
always extended Node.Cookie)
Comment 2 Jesse Glick 2004-09-30 14:43:06 UTC
So the desired style for new APIs is not to use Node.Cookie; you can
make JMIElementCookie not extend it, and put it into lookup, or put
the org.netbeans.jmi.javamodel.Element directly into the node's
lookup. (If it is too slow to compute, you could perhaps put in a
placeholder proxy object.)

For the compatibility layer of course you want to support getting the
o.o.s.Element from getCookie and perhaps also from lookup.
Comment 3 Jan Pokorsky 2004-09-30 15:36:10 UTC
The desired style is to provide o.n.j.j.Element directly in lookup.
The cookie was introduced just due to FilterNode malfunction. The
element is available during the node construction, no need for

The compatibility is guaranteed even now. You can get o.o.s.Element
from getCookie and from lookup.

The cookie is pretty spread out (java, refactoring, javadoc, editor,
clazz) but except the java bridge (issue #49741) it should not be
difficult to remove it.

Will I have to go through some review process?
Comment 4 Jaroslav Tulach 2004-10-01 07:31:31 UTC
Please use fasttrack and attache diff of updated documentation
describing what you do here. 

I'd like to suggest improvements to javadoc of JMIElement to mention
where to obtain the instance and also write into javamodel or javacore
arch document something like <api ... group="lookup">Various nodes
like ... offer <a href="@TOP@/.../Element.html">JMIElement</a> from
its lookup you can use node.getLookup().lookup(JMIElement.class or
subclass), blablabla</api>. As this might be one of the main usecases
you want to support I also suggest to update answer for usecases with
something like <usecase id="get-java-element" name="How to get
org...Element">same description and sample code</usecase>.
Comment 5 Martin Matula 2004-10-06 14:19:18 UTC
I've added the documentation. The diff is attached.
Comment 6 Martin Matula 2004-10-06 14:20:03 UTC
Created attachment 18085 [details]
Arch document diff.
Comment 7 Jan Pokorsky 2004-10-07 13:56:17 UTC
ok, so the review can start
Comment 8 _ tboudreau 2004-10-09 04:07:14 UTC
If you do change or remove this, please let me know - it will break a couple features of 
Comment 9 Jan Pokorsky 2004-10-14 14:12:45 UTC
No objection, so I am going to commit the remove of JMIElementCookie.
Comment 10 _ tboudreau 2004-10-14 16:04:08 UTC
Please post exactly how I should modify Navigator so I can still find the Element from the 
activated node.
Comment 11 Jan Pokorsky 2004-10-14 16:35:37 UTC

  JMIElementCookie jc = (JMIElementCookie)
  Element el = jc.getElement();

  Element el = (Element) node.getLookup.lookup(Element.class);

See also usecase in

I will integrate the change tomorrow to comply with fast review rules.
Comment 12 Jan Pokorsky 2004-10-19 14:55:10 UTC
fixed in

new revision: delete; previous revision: 1.3
new revision: 1.111; previous revision: 1.110
new revision: 1.20; previous revision: 1.19
new revision: 1.8; previous revision: 1.7
new revision: 1.32; previous revision: 1.31
new revision: 1.8; previous revision: 1.7
new revision: 1.14; previous revision: 1.13
new revision: 1.13; previous revision: 1.12
new revision: 1.30; previous revision: 1.29
new revision: 1.43; previous revision: 1.42
new revision: 1.11; previous revision: 1.10
new revision: 1.14; previous revision: 1.13
new revision: 1.8; previous revision: 1.7
new revision: 1.8; previous revision: 1.7
new revision: 1.10; previous revision: 1.9
new revision: 1.20; previous revision: 1.19
new revision: 1.9; previous revision: 1.8
Comment 13 Quality Engineering 2007-09-20 12:08:15 UTC
Reorganization of java component

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