Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 144852 - JavaSource shall not create DataObjects when searching for Documents
JavaSource shall not create DataObjects when searching for Documents
Product: java
Classification: Unclassified
Component: Source
All All
: P4 (vote)
: 6.x
Assigned To: Jaroslav Tulach
Depends on:
  Show dependency treegraph
Reported: 2008-08-22 13:34 UTC by Jaroslav Tulach
Modified: 2009-07-23 17:07 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-08-22 13:34:15 UTC
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:

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. 
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?
Comment 1 Vitezslav Stejskal 2008-08-22 15:03:17 UTC
V1: Why DataEditorSupport? Wouldn't it be better to have this new API 'Datasystems free'?
Comment 2 Jesse Glick 2008-08-22 15:20:31 UTC
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.
Comment 3 Jaroslav Tulach 2008-08-22 16:53:15 UTC
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?
Comment 4 Jaroslav Tulach 2008-08-28 07:33:56 UTC
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.
Comment 5 Jaroslav Tulach 2009-07-23 17:07:17 UTC
No additional indication that this is a significant flaw. Probably no need to invent some futuristic API to solve this 

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