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:
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.
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
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