Created attachment 17578 [details]
test's log

Either for Yarda or pnejedly?

This could never work. I'd like to know what I was thinking about
during commit.

Checking in unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java;
/cvs/openide/test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java,v
 <--  DefautDataObjectHasOpenTest.java
new revision: 1.6; previous revision: 1.5

The tests fails again on solaris. 

the testComponentCanBeSerialized:

      junit.framework.AssertionFailedError: DataObject can disappear
org.openide.loaders.DefaultDataObject@1a62c31[AbstractFileObject@64c34e[file:/var/tmp/fstests/lfstesttestComponentCanBeSerialized/AA/a.test]]
	at junit.framework.Assert.fail(Assert.java:47)
	at org.netbeans.junit.NbTestCase.assertGC(NbTestCase.java:844)
	at
org.openide.loaders.DefautDataObjectHasOpenTest.testComponentCanBeSerialized(DefautDataObjectHasOpenTest.java:258)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)

I know this fails from time to time because there may be a reference
from AWT static variables. I'd like to know whether Petr N. has some
advice how to solve this. I have two problems:

1. I am not exactly sure what the object reference chain is as I am
not able to simulate the problem right now. Incorporate insane into
assertGC? Only run it if its classes are on classpath? 

2. When we find what is wrong, what do we do? Use reflection to
cleanup some static variables in assertGC?

Meanwhile I can disable the test, if seen important.

"I know this fails from time to time" - somebody else who might have
to maintain this test in future might not know this and can spend
hours trying to figure out what's wrong. This is my experience with
Datasystems tests. I would suggest to put test like this one into a
special test bag like "known-to-fail-from-time-to-time" and keep them
there until they run reliably and *always* pass and if not there is
really a P2 problem. In my opinion unit tests which are randomely
failing are useless. On the other hand I understand that some our code
is hard to test reliably and so maybe special metric should be used
for tests from "known-to-fail-from-time-to-time" test bag: if a test
failed repeatedly 10? times in row then there is a problem and
somebody should look at it. It is P3 warning that something *might* be
wrong. Obscure, but better then current state when I'm getting P2
issues and  have to look at tests whose author maybe knew that they
might fail from time to time.

My experience from loader tests and especially CLIHandlerTest is that
even a test fails from time to time, it is possible (and desirable) to
fix it. I usually do that by improving logging in the test, so when it
fails I have idea what happened and in what order.

The problem with DefautDataObjectHasOpenTest is a bit different. I
know where the problem is (at least I think): the test opens a window
and then closes it and waits for it to be garbage collected. However
if the mouse pointer is inside the opened window the AWT calls
"updateCursorPointerImmedaitelly" and holds a pointer to the window
from a native code. So I do not need to improve logging (except using
insane to exactly know the reference path), but find a workaround to
prevent this.

Which I think I have. We could introduce a property in
DefaultWindowManager that would instruct it to perform all operations,
but without showing the JFrame on the screen and use that in our
tests. That would be more polite than blinking windows on our monitors
anyway.

Option?

cvs ci -m "#48927: Sometimes the lastSelected field could hold a
pointer to already closed Pane. Now we are using WeakReference instead
to allow it to be GCed."
cvs commit: Examining .
Checking in CloneableEditor.java;
/cvs/openide/src/org/openide/text/CloneableEditor.java,v  <-- 
CloneableEditor.java
new revision: 1.80; previous revision: 1.79
done
Checking in CloneableEditorSupport.java;
/cvs/openide/src/org/openide/text/CloneableEditorSupport.java,v  <-- 
CloneableEditorSupport.java
new revision: 1.134; previous revision: 1.133

the test fails again on solaris

Created attachment 18041 [details]
test log

cvs -q ci -m "#48927: Catching the assertGC exception until issue
49929 is implemented."
Checking in
test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java;
/cvs/openide/test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java,v
 <--  DefautDataObjectHasOpenTest.java
new revision: 1.7; previous revision: 1.6

test passed