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 20022 - DataObject.createFromTemplate returns an unconstructed Data Object
Summary: DataObject.createFromTemplate returns an unconstructed Data Object
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: David Konecny
Depends on: 12853
  Show dependency tree
Reported: 2002-02-01 02:18 UTC by Michael Ottati
Modified: 2008-12-22 16:00 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Solution to the DataObject constructor problem with a test (12.80 KB, patch)
2003-04-30 18:45 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Ottati 2002-02-01 02:18:53 UTC
I have a MultiDataObject with a static factory method used to create new 
instances from templates. On the return from:

MyDataObject dob;
  try {
    dob = (MyDataObject)template.createFromTemplate(moduleFolder, moduleName);
    if (!dob.isConstructorComplete()) {
        ERROR CONDITION ........ 

I receive a reference to the data object that was just created however it is 
not fully constructed. In order to test this theory, I added some code in the 
constructor of the data object and set a boolean as the last line of the 

The new isConstructorComplete() method returns false after the 

It appears to me that I am getting a handle to an object that has not completed 
it's constructor. I am able to reproduce this with regularity on a 2 processor 
Win2K machine running the Forte4Java build of Jan 31, 2002.

If I am getting a handle to a not fully unconstructed object, this seems very 
wrong to me. Based upon my analysis, this seems to be what is happening.

The static method 
--------- Constructor Portion 

    private boolean constructorComplete = false; 
    public MyDataObject(FileObject pf, MultiFileLoader loader)
    throws DataObjectExistsException {
        super(pf, loader);
         synchronized (this) {

    private synchronized void  setConstructorComplete(boolean value) {
        constructorComplete = value;
    private synchronized boolean isConstructorComplete() {
        return constructorComplete;

Comment 1 phamernik 2002-02-04 16:59:28 UTC

it looks like known problem. The problem usually occurs when the
initialization of your dataobject is too long and more than one thread
is touching the data object. 
What are you doing in the constructor of your dataobject?

Comment 2 Michael Ottati 2002-02-05 07:57:29 UTC
Your answer raises a number of troubling questions.

You state that this a known problem. Known to whom? I see no  mention
of this either in the javadoc for the createFromTemplate method nor in
the general documentation for DataObject. I also see no reference to
another Issuezilla bug.

Am I wrong in interpreting the the createFromTemplate as being a
factory method for data objects? I was under the impression that I had
an implicit contract with a constructor (or factory method) of
?Guaranteed initialization with the constructor?.

In answer to your question regarding what I am doing in my
constructor, I am doing quite a bit. Reading and writing files,
perhaps these files reside on remote high latency networks. Is this a
problem? Is it documented?

I have not followed the whole chain of events but it appears that my
DO is being put into a data object pool by one thread picked out of
the pool by another, without being given the opportunity to execute
the constructor code through to completion. If this is what actually
happens, it is a  thread hostile situation requiring strict usage
guidelines in the javadoc.

Comment 3 phamernik 2002-02-05 11:25:59 UTC
I agree this problem is not documented. I am going to add the
description to javadoc immediately. The only information about it is
in DataObjectPool, but these comments are not part of javadoc:

/** A delay to check the notify modified content. It is expected that
 * in 500ms each constructor can finish, so 500ms after the registration
 * of object in a toNotify map, it should be ready and initialized.
 private static final int SAFE_NOTIFY_DELAY = 500;


This is an architecture issue and unfortunatelly it can't be fixed
without the large rewrite of data system. It is supposed it will be
solved in NetBeans 4.0.

The problem can occurs when:
- DataObject's constructor takes more than 500ms
- Some other thread obtains this dataobject when constructor is still

It is not possible to prevent other threads from getting the data
object when it is already registered (e.g. from compilation, explorer,

Please move the time consuming code from constructor if possible.

Hope this description helps.
Comment 4 phamernik 2002-02-05 16:06:21 UTC
The better documentation was added to DataObject and MultiDataObject.
Changing target milestone -> 4.0
Comment 5 Michael Ottati 2002-02-06 08:23:35 UTC
This appears to be an duplicate of:

How did 12853 ever get marked resolved? The last comment in it by 
Chris Webster indicates that the problem was not fixed.

Is there an idiom that can be used in a MultiDataObject constructor 
that can be used to GUARANTEE thread saftey? Based upon Joe, Chris 
and my own analysis, I believe not given the current architecture.

Is there any way to allow the outermost data object to perform the 
DataObjectPool registration itself? Once an unconstructed object gets 
into the pool, it seems all bets are off as regards thread saftey.
Comment 6 Jaroslav Tulach 2002-02-08 10:08:11 UTC
I believe that issue 12853 is resolved. If the DataObject constructor
does not take too long (more than 500ms) everything should work.

The current architecture does not allow good solution of this problem.
This will be solved with the datasystem rewrite.

Michael, your solution to allow the object to notify the pool that it
is finished worth attention. I suggest add to modify MultiDataObject
in following way:

1. add new constructor MultiDataObject (FileObject fo, MultiFileLoader
loader, boolean willNotifyWhenCreated)
2. add a method protected final void notifyCreated () 

Michael would use the constructor with 3rd argument == true and when
his constructor finishes he would call notifyCreated (). The
DataObjectPool would treat such data objects in a special way and stop
doing all the magic it does currently.

Still this is not excelent solution, but in current architecture we
can hardly hope in better.
Comment 7 Chris Webster 2002-03-22 19:03:49 UTC
In my opinion all data objects should be created using the new
constructor proposal. If the data objects are created via a loader,
the invoker of createMultiDataObject method would have the
responsibility of the create notification. This would alleviate the
design problem where a DataObjectExists exception is thrown from the
constructor of DataObject. 
Comment 8 Jan Chalupa 2002-04-16 13:31:15 UTC
Requesting a waiver for FFJ 4.0 (Orion).

Architectural problem. Cannot be fixed reliably for Orion.
Comment 9 Jan Chalupa 2002-05-02 10:43:43 UTC
Waiver approved.
Comment 10 Jaroslav Tulach 2002-07-26 07:58:17 UTC
This bug is reported in version <= 3.4dev and still not fixed. Due to that it
forbids the release candidate for 3.4 to be promoted. Are you aware of that and
are you intensively working on the fix? If not, you should consider some
corrective action.
Comment 11 iformanek 2002-07-31 10:18:15 UTC
I agree with the waiver
Comment 12 John Jullion-ceccarelli 2002-08-01 09:42:15 UTC
Docs agrees with wavers. I am leaving Patrick on the CC 
for his records.
Comment 13 David Strupl 2003-02-05 15:57:40 UTC
I am sorry but this will not be fixed in 3.5. Changing target
milestone to 4.0.
Comment 14 Marian Mirilovic 2003-03-13 13:42:21 UTC
Changed owner David S. -> David K.
Comment 15 David Konecny 2003-04-30 10:45:08 UTC
Changing TM to "FUTURE" which is more appropriate, because at the
moment I do not plan to fix this issue for next version. Let me know
if you disagree. I'm open to change the plan.
Comment 16 Chris Webster 2003-04-30 16:15:21 UTC
I think the atomicity of "DataObject"s or there replacements and the
recognition and construction should be requirements for the new
DataSystems. A DataObject is not locatable until 1. it is fully
constructed 2. the associated files have been fully constructed. This
functionality should be provided via the underlying infrastructure.
Comment 17 Andrew Sherman 2003-04-30 17:06:11 UTC
When I see a change like this what I really want to know is 'what it
means'. Does this mean that someone has decided there will be no Data
Systems rewrite in 4.0? Or there will be a rewrite but this bug won't
be addressed? Does this mean that there will be a 4.0 without
Projects? Or will there be another NB version before Projects?
Comment 18 Jaroslav Tulach 2003-04-30 18:45:17 UTC
Created attachment 10198 [details]
Solution to the DataObject constructor problem with a test
Comment 19 Jaroslav Tulach 2003-04-30 18:49:13 UTC
I'd like to present a solution to all the DataObject constructor
problems. It solves the need for knowing when a constructor is
finished by forcing every code to use 

DataObject.find (...);

or a similar method - this is the behaviour that 99.9% of all code
does. So I think it worths to try. The only reason why this has not
been implemnted few years ago was the 0.1% of usages that could be
broken and we were so possesed by compatiblity that we rather lived
with broken code than to change it incompatibly.

So what do you think? 
Comment 20 David Konecny 2003-05-06 16:23:00 UTC

what this means? That I do not plan to fix this issue for 4.0 (ie.
next version) in current DataSystems. That's why I set TargetMilestone
to "future". Nothing more.

I changed TM intentionally to learn *from you* more about this issue
and either put it into my plans for next version or not. 

The rewrite of the DS is still planned and all problems of the current
system (including this one) have to be addressed. However it is not
clear when it will be finished and into which version it will get.

Btw. I'm currently working on extracting settings capabilities of
current datasystem (InstanceDO, XMLDO) into separate library (Registry
API). Then I would like to continue where DavidStrupl stopped with
FileSystem Extensions. 

So from my point of view I do not want to waste my time fixing issues
in library which will be discarded. I would rather invest all my time
into the new DS. But on the other hand I know that this issue is
serious for you and so I need to know whether I should rather fix it.
On the other hand if you switch to new projects you will not need this
anymore. But I do not know your plans. Too many unknowns. :-) We do
not have to resolve this right now. I just wanted to express how I'm
thinking about this issue and synchronize it with your expectations.

And Yarda already attached the patch! It might break something but at
least we already have a solution. Because of possible breakage I would
wait with the commit till you clearly state that you want me to fix
this and that your next version will still be using current
DataSystems. Without that would be fixing useless and possibly only
destabilize other API clients. Thanx.
Comment 21 Andrew Sherman 2003-05-06 17:52:50 UTC
Thanks for the clarification.  Now I understand what you mean :-) We
are committed to Projects, barring major disaster or high level
management stupidity.  So I think you should not bother with this bug
and concentrate on moving forward as you suggest.  Chris do you agree?
Comment 22 Chris Webster 2003-05-06 18:16:51 UTC
The current design is reliant on projects at this point attempting to
implement some of the proposed changes without projects would either
have a significant negative impact on schedule or the feature itself.
Please work on the new DataSystems.

Comment 23 Michael Ottati 2003-05-06 19:50:48 UTC
I am confused. Where is a list of what we are planning for 
4.0? If there is a thread safe alternative to DataObjects 
slated to be released in conjunction with projects, then 
that effectively eliminates the issue for me.

Note that this issue has festered since June 2001 (see IZ 
12583). I think it is reasonable to request a thread safe 
version of data systems for 4.0. This does not necessiarly 
entail fixing the current data systems, we will be 
modifying our S1S code to work with the new projects/DS 
implementations anyway. Doing this work in the new code 
base is preferable.

What is confising about this dialog is that we dont know 
which DS we will be basing the next release of S1S on.

Comment 24 David Konecny 2003-05-07 08:41:58 UTC
"Where is a list of what we are planning for 4.0?" - I afraid there is
no list at the moment. I was only evaluating all the issues assigned
to me in issuezilla and was updating their state to be more precise.

The best source of information about what is happening in core can be
found at <>.

"If there is a thread safe alternative to DataObjects 
slated to be released in conjunction with projects, then 
that effectively eliminates the issue for me." - the new projects is
this alternative. Andrew knows more from his visit in Prague.
Comment 25 Jaroslav Tulach 2003-05-16 13:24:30 UTC
Nobody can get a grip on unconstructed data object since issue 33469
has been implemented.
Comment 26 Marian Mirilovic 2005-07-13 13:22:41 UTC