I just spent a while debugging SourcesHelper,
whose updated test seemed to fail occasionally,
until I realized I was failing to hold a strong
ref to a listener passed to WeakListeners. This
meant (I am guessing) that if GC happened to run
at the wrong time, some critical event would not
get delivered.

I imagine this kind of problem can be frequent; GC
indeterminism can be just as harmful to unit
testing (and code quality) as threading
indeterminism, though easier to fix once you know
what is wrong.

Suggest that a new class be added to
org.openide.util called e.g.
InstrumentableWeakReference, extending
WeakReference, and that all calls to WR's
constructor be replaced with IWR. Its default
behavior would be identical to WR, but you could
set some system properties to control it. In one
mode, it would actually hold a strong reference to
its referent, simulating GC that doesn't happen
soon enough; in another, it would call System.gc
before delegating get() to super, simulating GC
that happens sooner than you expected.

You could set these system properties statically
in tests if you really wanted, or even in the IDE
(slow!), but more usefully NbTestCase could have
some overridable method like

    protected boolean
debugWeakReferenceIndeterminism() {
        return false;
    }

If true, whenever a test method failed, it would
be retried in both of the above modes; according
to the results, it could report the failure with a
special message giving you a hint to check your
weak references. (I.e. you might be assuming that
a weak ref gets collected when it might not be, or
it might be collected when you were not expecting
it to be.)

Sound useful?