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.
Issue 144131 indicates that all the Retouche clones are likely creating a lot of DataObject just to find out if there is an open document for a file object. This may be very inefficient, especially if some data loaders are not written correctly. See the following thread dump: http://www.netbeans.org/nonav/issues/showattachment.cgi/67591/nb.stackdump jlahoda suggested: Well, what we have is a FileObject, what we need is a Document for this file, if it exists, or null if it does not. The journey how we get the Document is not very important for us. But, from your description, all possible solutions look like hacks. Not sure that we should introduce these hacks into the Java support - it would be much better if there were an API method that would get a FO and would produce DataObject.find(file).getCookie(EditorCookie.class).getDocument(), efficiently. Then we could use the method through the IDE (I would assume the other language supports and/or GSF would use very similar approach). OK, let's add public static Document DataEditorSupport.findDocument(FileObject fo), ok?
V1: Why DataEditorSupport? Wouldn't it be better to have this new API 'Datasystems free'?
I don't get it. What would the method do, other than create the DataObject and ask it for an EditorCookie? Data objects are permitted to load Document's in special ways, e.g. applying some conversions from the disk file. If the call to DataObject.find is currently too slow, I would suggest optimizing this directly. It is said that "some data loaders are not written correctly" but there is no explanation of what is incorrect and why it cannot be fixed without an API change.
Re: V1. independent from DataSystems? Where we would put that API? To editor? There is the Document property StreamDescriptionProperty, maybe you could have a map from all StreamDescriptionProperty to Documents somewhere? Do you want to do it?
After lively discussion with Jan I can only agree that I do not have any numbers to measure how much time this behaviour really consumes.
No additional indication that this is a significant flaw. Probably no need to invent some futuristic API to solve this issue.