Seems 100% reproducible. Open javacard.project. Run Find Usages on, for example, AIDPanel. Double click a usage from
another form (may be reproducible with any Java source; reproduced it twice with forms). IDE deadlocks.
See attached thread dump - classic deadlock:
- Editor initialization thread is inside a CloneableEditor.DoInitialize, waiting for the AWT tree lock (it is
constructing a JEditorPane on the wrong thread)
- AWT thread is holding the AWT tree lock and waiting for the CloneableEditor.DoInitialize to complete
Created attachment 89349 [details]
Also happens if you right-click any form and choose Edit. Workaround: Open the form editor first, then switch to the
My guess is this is caused by a different initialization sequence when the source editor appears inside a multiview.
Marek, can you please have a look?
NbEditorKit.call should not access AWT hierarchy because it is called outside AWT. Passing to Vita.
Trying to fix...
local changeset: d29a273d9541
*** Issue 174528 has been marked as a duplicate of this issue. ***
The fix is now in http://hg.netbeans.org/jet-main/rev/d29a273d9541, which is a child of 6ebeddb99737, which introduced
the problem. Therefore d29a273d9541 can be directly applied to team repositories simply by:
hg fetch -r d29a273d9541 http://hg.netbeans.org/jet-main
*** Issue 174475 has been marked as a duplicate of this issue. ***
*** Issue 174555 has been marked as a duplicate of this issue. ***
*** Issue 174564 has been marked as a duplicate of this issue. ***
The fix looks ok for a hotfix, but:
1. The JEditorPane subclass does not need to be an anoymous inner class with a reference to the NbEditorKit that created it, it can be a nested class (also
preferable for debugging things as it is easier to find in source). Same for the BaseTextUI subclass - neither one needs a reference to the instance that
created them, so they should not be inner classes at all.
2. The JEditorPane is still constructed on a background thread. Having updateUI() be a pseudo-no-op *probably* fixes the problem of the tree lock being
taken inside its constructor, but it does not guarantee it - anyone implementing AWT and Swing (Apple, Classpath, whoever) could easily run some code that
does take the tree lock in some superclass constructor. If there is really no choice except to create the JEditorPane in a background thread, that is a design
bug that needs to be fixed.
Reopening as P4 w/ changed summary, pending a more maintainable fix.
Tim, in this case I prefer to have this report closed with the original summary, etc. There are many duplicates and more
are still coming. It's confusing to duplicate them to an issue that apparently has nothing to do with the problem.
Please open a new issue if you still feel like doing so. Back to you questions:
ad #1 - I'm sorry, but I don't understand. What is the difference between 'inner class' and 'nested class'. Anyway, are
you saying that I should have created 'private static final class J extend JEditorPane ...' and the same for the BaseTextUI?
ad #2 - You are right. This was done solely to make the slowness detector happy, ie. to pre-load classes related to
highlighting layers *outside* of AWT. So, yes, it is a design bug - how do you preload swing classes outside of AWT?
Integrated into 'main-golden', will be available in build *200910150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vita Stejskal <firstname.lastname@example.org>
Log: #174408: using fake BaseTextUI to prevent AWTTreeLock access
*** Issue 174618 has been marked as a duplicate of this issue. ***
> Anyway, are you saying that I should have created 'private static final class J extend JEditorPane ...' and the same for the BaseTextUI?
Yes. Inner classes are more expensive.
Not pretty, but I did something like this in the new mobility project wizard to bring project creation time down to an acceptable level. ClassPreloader.start()
is triggered in a static block when the first mobility project wizard panel is created; ClassPreloader.stop() is called when the code that actually needs the
classes starts to run:
If it's just classloading that is causing your problem, this can help. On the other hand, maintaining the list of classes is not fun.
I've created issue 174683 to track the component creation problem.
ad#1 - Ok, I'll do that.
ad#2 - Thanks for the advice, but I'm not going to do this. If anything like that is needed in Netbeans then we should
have some general policy/recommendation how to do things like this. I don't want to do this adhoc. Plus, I think my
situation is a little bit more complicated, because of the use of Lookup - I don't know all the classes that I might
find in the Lookup when looking up for example HighlightingsLayerFactory. But I don't think this is really that much of
*** Issue 174575 has been marked as a duplicate of this issue. ***