Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 156829 - Deadlock creating Java ME project
Deadlock creating Java ME project
Product: serverplugins
Classification: Unclassified
Component: Infrastructure
All All
: P2 (vote)
: 6.x
Assigned To: Petr Hejl
Depends on:
  Show dependency treegraph
Reported: 2009-01-14 16:34 UTC by _ tboudreau
Modified: 2009-02-22 07:53 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT

Thread dump (36.88 KB, text/plain)
2009-01-15 04:34 UTC, _ tboudreau
Here is a test showing the problem with initialization of JSeparator outside of AWT thread (5.42 KB, patch)
2009-01-19 09:24 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2009-01-14 16:34:06 UTC
Fresh build.  Create a new Java ME project.  You will be asked to "activate" mobility.  Scrollbar runs for a while, then
UI freezes.  Event thread is blocked here:
        - locked <0x1d25a120> (a org.openide.util.RequestProcessor$Task)
        at org.openide.util.RequestProcessor$Task.waitFinished(
        at org.openide.loaders.FolderLookup$Dispatch.waitFinished(
        at org.openide.loaders.FolderLookup$ProxyLkp.beforeLookup(
        at org.openide.util.lookup.ProxyLookup.lookup(
        at org.openide.util.lookup.ProxyLookup.lookup(
        at org.netbeans.modules.j2ee.deployment.impl.Server.<init>(
        at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry.addPlugin(

Guessing this is really related to the ergonomics changes.
Comment 1 Thuy.d Nguyen 2009-01-14 22:02:52 UTC
I've just tried the trunk build #4806 with fresh userdir and can not reproduce the issue. After "activate" mobility, I
get to the second step of the wizard which asks me to install a J2ME platform. From then I can continue the wizard till
it finishes. A J2ME project is created and no such exception thrown.

Do you have specific steps to reproduce the issue?  Which jdk is your IDE running? or the issue might have been fixed in
the latest build.
Comment 2 _ tboudreau 2009-01-15 04:34:10 UTC
I gave the specific steps;  maybe it is windows specific?

Microsoft Windows XP [Version 5.1.2600]
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

Talk to Karol Hazerlak, as he mentioned he saw the same problem when we talked on the phone today.  I'll attach the
thread dump - sorry I forgot to do that before.
Comment 3 _ tboudreau 2009-01-15 04:34:39 UTC
Created attachment 75847 [details]
Thread dump
Comment 4 _ tboudreau 2009-01-15 04:46:19 UTC
Both the "Ergonomics" thread and the AWT event thread, and a Request Processor thread that loads database drivers, and
another thread that loads language support, are waiting on 0x1d25a120;  the AWT thread is holding a *lot* of locks; 
some other thread is probably directly or indirectly deadlocking with one of them:

- locked <0x1d25a120> (a org.openide.util.RequestProcessor$Task)
- locked <0x35a111b0> (a org.netbeans.modules.j2ee.deployment.impl.ServerRegistry)
- locked <0x35d0f930> (a org.netbeans.modules.server.ui.node.RootNode$ChildFactory)
- locked <0x1295b710> (a java.lang.Class for org.netbeans.modules.server.ui.node.RootNode)
- locked <0x35d0fa98> (a java.lang.Object)
- locked <0x1cb7b880> (a java.awt.Component$AWTTreeLock)

This is probably your culprit - a familiar culprit, the AWT tree lock:
"Lookup Dispatch Thread" daemon prio=2 tid=0x05a81400 nid=0x27b4 waiting for monitor entry [0x067cf0
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.awt.KeyboardFocusManager.clearMostRecentFocusOwner(
        - waiting to lock <0x1cb7b880> (a java.awt.Component$AWTTreeLock)
        at java.awt.Component.setFocusable(
        at javax.swing.JSeparator.<init>(
        at javax.swing.JSeparator.<init>(
        at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm
        at java.lang.reflect.Constructor.newInstance(
        at java.lang.Class.newInstance0(
        at java.lang.Class.newInstance(
        at org.openide.loaders.InstanceSupport.instanceCreate(

What this suggests is that actually creating JSeparator instances in folders to define menus is very likely to construct
components off the AWT thread, and probably the real long-term fix is not to use that class to declare separators in
menu/toolbar definitions, since it is relatively common to load a bunch of actions on another thread.

Since the problem appeared with the introduction of ergonomics code, probably this issue should be refiled there, but
the JSeparator issue appears dangerous.
Comment 5 Jesse Glick 2009-01-15 18:58:31 UTC
Note the new keyword.

Probably RootNode$ChildFactory.init should be doing its work asynch.
Comment 6 Thuy.d Nguyen 2009-01-16 00:27:26 UTC
Reassigning to ergonomics for further evaluation. 
If anything we need to do on our part, please give a specific guideline/advice.
Comment 7 Jesse Glick 2009-01-16 00:58:25 UTC
Please remember to use "Reassign issue to owner of selected subcomponent" whenever changing component/subcomponent.
Comment 8 Jaroslav Tulach 2009-01-19 09:24:52 UTC
Created attachment 75968 [details]
Here is a test showing the problem with initialization of JSeparator outside of AWT thread
Comment 9 Jaroslav Tulach 2009-01-19 09:31:14 UTC
I've just attached a patch to show that the code in db module is not fully correct. It can deadlock with AWT thread, 
exactly as in the originally reported thread dump. I guess the test is good enough proof to let me modify the list of 
keywords and reassign to db module maintainers. My hint: use actionsForPath instead of inventing your own way to load 
Comment 10 _ tboudreau 2009-01-20 03:41:04 UTC

I do wonder if we shouldn't open a separate issue for this - it would be pretty easy to create an empty class
org.openide.util.Separator and change all separator declarations to that, and log a warning when JSeparator is
encountered.  Since you can create a menu/toolbar presenter when you want, I don't think there is a real reason to
support declaring random Swing components in a layer for a menu or toolbar anyway.

Or something like
<attr name="separatorAfter" boolvalue="true"/>
Comment 11 Rob Englander 2009-01-20 12:59:43 UTC
Hi, I'm the guilty party, or so I thought.

jtulach, you said your test proves that the db module code that loads actions
is not fully correct, and suggested I use Utilities.actionsForPath instead of
the code that was there.  I'm fine with doing that, but when I looked at the code
for actionsForPath it was remarkably similar to the code in the db module.  In fact,
it's more than similar.  It's almost exactly the same thing.  So before I go ahead and
make the change, can you please explain how this solves the deadlock problem?
Comment 12 Rob Englander 2009-01-21 19:16:59 UTC

No longer using JSeparator to separate DB explorer actions in the layer file.  
Comment 13 Jesse Glick 2009-01-21 21:02:39 UTC
I don't think this is a good fix. _All_ other places in the platform and IDE which define context menus consistently use
javax.swing.JSeparator to indicate separators.

1. Utilities.actionsForPath can be changed to enumerate Lookup.Item's and avoid actually constructing JSeparator's,
which would be an improvement generally. (All code which constructs context menus from layer folders should be using
actionsForPath.) core-main #6578a110d2aa

2. As I said some time ago, org.netbeans.modules.server.ui.node.RootNode$ChildFactory.init should probably be
constructing its children incrementally in a background thread anyway.
Comment 14 Rob Englander 2009-01-21 21:41:34 UTC
Please assign this to the appropriate person.  I'll leave my fix in place
so that the database module is not inflicting a P1.  When this is addressed
I'll be happy to undo my changes.
Comment 15 Jesse Glick 2009-01-21 22:55:02 UTC
phejl seems to be the author of Perhaps he can consider my #2 suggestion, and reporter/reproducer can
also check whether my #6578a110d2aa (once merged to main) cures the symptom of the deadlock as well.
Comment 16 Jesse Glick 2009-01-21 22:56:33 UTC
One way or the other, #bb969818b352 is incorrect and should be backed out.
Comment 17 Rob Englander 2009-01-21 23:37:05 UTC
Incorrect?  I don't agree.  I'll agree with unnecessary ;)
Comment 18 Jesse Glick 2009-01-22 01:14:09 UTC
Using anything other than JSeparator to indicate menu separators is inconsistent with precedent and should not be
allowed in any module. In particular, ActionSeparator is an unreviewed API change (it is in a public package).

#6578a110d2aa is main so I am downgrading priority on the assumption that this fixes the bug symptom.
Comment 19 Rob Englander 2009-01-22 02:17:17 UTC
36a8ae3554e7 db module reverted to original code.  The deadlock is not caused by the db module.
Comment 20 Quality Engineering 2009-01-23 07:31:15 UTC
Integrated into 'main-golden', will be available in build *200901230201* on (upload may still be in progress)
User: Rob Englander <>
Log: #156829 Stop using JSeparator to separate actions in the layer file for the db explorer.
Comment 21 Petr Hejl 2009-02-19 15:11:30 UTC
#2 fixed in main 76006fbfb331.
Comment 22 Quality Engineering 2009-02-22 07:53:35 UTC
Integrated into 'main-golden', will be available in build *200902220201* on (upload may still be in progress)
Log: #156829 Deadlock creating Java ME project (init children asynchronously)

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo