Created attachment 3245 [details]
FTD

The deadlock happened during reading FileSystems XML attributes.

The recent change in openide.util.Utilities (1.70 - bugfix of #17164) 
caused that AWT-EventQueue thread went through 
- reading (deserialization) of XML attributes (synchronized method)
- Utilities.translate
- Utilities.getSystemClassLoader
- and finally waited for Folder recognizer thread

The Folder Recognizer thread was waiting for reading XML attributes 
and so never ended.

The problem was fixed by reverting the change 1.70 in Utilities (see 
revision 1.72).

In fact I did not reverted Lookup usage as it was required by Yarda.
TopManager is forbidden in Utilities however it was used in previous
version. Going to use TopManager again.

Created http://openide.netbeans.org/issues/show_bug.cgi?id=17363

Utilities (see revision 1.73)

In which previous version? If you really need, code it with
reflection, but do not break whole usage of utilities just because of
this.

Petr Kuzel is working on this. Reassigning to Petr K.

Look at 1.69 there was really used TopManager. Just you, Yarda, warned
me not to use it there (see #17431), but it does not work without it.
Anyway you are right application platform will require to distingvish.

May be, Jesse suggested to use a startup class loader (I do not know
nothing like it, is it a core private classloader?) to solve it. So I
can proceed with Utilities.class.getClassLoader() however it sounds to
me like a functionality by a chance.

I do not buy your suggestion to use reflection to reach TopManager.

I need to get to the system class loader in clean way. <sorry>Do I ask
a lot?</sorry>

I see the problem with allInstances() as Lookup.getDefault() is the
composite lookup and must also wait for FolderLookup in spite of the
fact that the result is known from TMLookup that is the first in the
composite. If it is not implementation dependent I can switch all
blocking calls that must return Lookup results to simple:

  Lookup.getDefault().lookup(ClassLoader.class)

I suppose it returns the first result so it will never wait for the
FolderLookup.

Resolved in Utilities 1.74.

Ok, but there is a small difference between
TopManager.systemClassLoader () and Lookup.lookup (ClassLoader.class)
I forgot to mention - the later can return null. The code does not
seem to be ready for that.

Resolved for 3.4.x or earlier, no new info since then -> verified

Resolved for 3.4.x or earlier, no new info since then -> closing.