For some time now (at least a couple of months in dev builds, observed
as recently as Mar 8 or so),
FolderInstanceTest.testFolderInstanceNeverPassesInvObjects has failed
for me consistently (JDK 1.3.1_02, Linux): at line 378 I get
"expected:<100> but was:<0>". Although this test has been failing for
me for a long time, it apparently does not fail for other people or in
the continuous QA tester, so I only now tried to investigate it.

In this test, folder/file{0-99}.simple are initially
DefaultDataObject's, and a FolderInstance counts the
SimpleDataObject's in the folder, so initially it is 0. After adding
the *.simple data loader to the loader pool, the folder/file*.simple
are invalidated, which is supposed to cause the DataFolder to fire
PROP_CHILDREN, which in turn causes the FolderInstance to be refreshed
and get the value 100. It does not work; debugging println's show that
the *.simple files are really invalidated, but the DataFolder never
fires the PROP_CHILDREN event (so the FolderInstance is left
unrefreshed at 0).

Less reproducibly, other datasystems tests can fail too; e.g.
DataFolderTest.testPropChildrenFiredAfterInvalidation which basically
has the same test setup, but specifically tests the PROP_CHILDREN
event rather than FolderInstance. I think the cause is the same.

On my machine I can reproduce the failure with this command, a
simplified form of the invocation used by XTest:

/space/jdk1.3.1_02/bin/java -Dsystem.dir=/space/src/nb_all/openide/test/work/sys -classpath 
/space/src/nb_all/openide/src:/space/src/nb_all/core/src:/space/src/nb_all/xtest/lib/junit-ext.jar:/space/src/nb_all/xtest/lib/junit.jar:/space/src/nb_all/cor
e/netbeans/lib/ext/regexp.jar:/space/src/nb_all/core/netbeans/lib/ext/crimson.jar:/space/src/nb_all/openide/test/unit/src 
org.openide.loaders.FolderInstanceTest

The bug is probably not a race condition: heavy machine loads do not
seem to change it, and increasing the 1000msec timeout in
FolderInstanceTest does not help.

Interesting note: if /space/src/nb_all/core/netbeans/lib/core.jar is
added to the end of the classpath, which does not affect classloading
but means that core's META-INF/MANIFEST.MF is available and so the
core module is loaded, the test succeeds! I have no explanation for
this; core.jar now has no loader sections, so perhaps the bug either
involves some aspect of garbage collection (and is not triggered in
different memory conditions); or the presence of additional folders in
the core layer causes the refreshing to work.

While inserting various debugging code into FolderInstanceTest and
other datasystems sources, I found out that if you attach a
PropertyChangeListener to one of the original data objects - e.g. the
DefaultDataObject for folder/file0.simple - before changing the loader
pool, the bug does not occur. If there is no PCL on this data object,
even if you make the PCL and attach but then immediately detach it
from the DDO, the bug occurs. I suspected some bug in
DataObject.firePropertyChange, but with or without the debugging
listener, the DDO correctly fires PROP_VALID to the
FolderList.Listener weak listener (which is not enough to trigger
PROP_CHILDREN however). Again it is possible the added listener simply
changes some aspect of memory usage and thus the timing of garbage
collection.

Anyway, I managed to get a detailed trace of the problem and compare
it to the correct behavior, by adding the listener or not. The problem
seems to lie in DataObjectPool.Validator.revalidate.

With the listener added to the DDO folder/file0.simple, during
revalidate() while processing this file, pool.findDataObject(fo,this)
throws a DOEE where both the orig and the object in the exception are
the original DefaultDataObject; at the end of the method, the
Set<DataObject> s contains just 'folder' and 'folder/file0.simple',
thus getPOOL().refreshAllFolders() is called, thus the FolderList
fires PROP_CHILDREN, DataFolder refires it, FolderInstance receives it
and refreshes, and the assertion in the test passes. (It still fails
later in the test because the next loader pool change does not fire
PROP_CHILDREN: perhaps because there is now no PCL??)

With no listener added, or the listener added but then removed: there
is no DOEE thrown, obj is now a SimpleDataObject (while orig is again
a DefaultDataObject), thus it is invalidated, thus s is empty (or
sometimes contains just 'folder' - I think I have seen both), and
since it is not true that size > 1, no refreshing occurs (note that
file0.simple thus behaves like file{1-99}.simple).

The bug can apparently be fixed, or at least no longer is visible, if
you change the bizarre line in revalidate:

if (s.size() > 1) getPOOL().refreshAllFolders();

to check >0 (or >=1); checking for 2 or more objects makes no sense at
all. However I think there are probably other things wrong in this
method. What is the meaning of the set 's'? It is completely
uncommented and unexplained in the source. Why would attaching a PCL
to one of the data objects cause the resulting 's' to be different?
Why are folders refreshed only if it is not the case that all data
objects have setValid(false) on them? What does it mean when a
DataObjectExistsException is thrown from the findDataObject method,
and why are general IOException's including this one caught and
ignored? This method probably needs a code review and/or more
comments explaining what it is doing and why.

Other suspicious things in nearby code that are probably not related,
but should be looked at anyway: (1) FolderInstance uses == rather than
equals() when checking for PROP_CHILDREN, which would break if some
DataObject.Container fired a PCE with a non-interned copy of
"children" as the property name. (2) FolderList uses double-checked
locking in some places, and no synchronization at all in other places,
when accessing the 'pcs' field holding its listeners; should clean up
synchronization here.