We are unable to open any java GUI form which uses SwingX !!!

Created attachment 100149 [details]
testcase,logs

This seems to be caused by fix of JDK's bug 5102804 (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5102804 ) that was integrated into JDK 6 update 21 build 2 according to http://download.java.net/jdk6/6u21/promoted/b02/changes/JDK6u21.b02.list.html

This fix resuls into new Introspector().getBeanInfo() being called with BEANINFO_CACHE lock held. This is deadlock prone. I will either try to find a reproducible test-case showing that this is unwanted regression or will add some workaround into GUI builder's code.

Created attachment 100196 [details]
Test-case showing problems with changes introduced in JDK6u21b02

I was able to create a simple standalone test-case that shows how easily one can face a deadlock when using JDK 6 update 21 (see the attachments). I will provide this test-case to JDK guys and will see if they are willing to fix the problematic synchronization in Introspector.

Can we expect some workarround these days?

> Can we expect some workarround these days?

There is one simple and straightforward workaround that you can use immediatelly: do not use bleeding edge (= early access) build of JDK, i.e., do not use JDK 1.6.0_21; use 1.6.0_20 or older.

JDK Standard Edition 6u21 is almost 6 months old and resolved about 410 bugs !

*** Bug 188050 has been marked as a duplicate of this bug. ***

Does this mean that we should go back to nb 6.8 which works with JDK 6u21 Build B05?

This could easily be fixed by the following change to the Introspector:


    public static BeanInfo getBeanInfo(Class<?> beanClass)
        throws IntrospectionException
    {
        if (!ReflectUtil.isPackageAccessible(beanClass))
        {
            return (new Introspector2(beanClass, null, USE_ALL_BEANINFO)).getBeanInfo();
        }

        Map<Class<?>, BeanInfo> beanInfoCache;
        BeanInfo beanInfo;

        synchronized (BEANINFO_CACHE)
        {
            beanInfoCache = (Map<Class<?>, BeanInfo>) AppContext.getAppContext().get(BEANINFO_CACHE);
            if (beanInfoCache == null)
            {
                beanInfoCache = new WeakHashMap<Class<?>, BeanInfo>();
                AppContext.getAppContext().put(BEANINFO_CACHE, beanInfoCache);
            }
            beanInfo = beanInfoCache.get(beanClass);
        }

        if (beanInfo == null)
        {
            beanInfo = (new Introspector2(beanClass, null, USE_ALL_BEANINFO)).getBeanInfo();
            synchronized (BEANINFO_CACHE)
            {
                BeanInfo oldBeanInfo = beanInfoCache.get(beanClass);
                if (oldBeanInfo == null)
                    beanInfoCache.put(beanClass, beanInfo);
                else
                    beanInfo = oldBeanInfo;
            }
        }

        return beanInfo;
    }

> This could easily be fixed by the following change to the Introspector

Yes, it can be fixed by a minor change in Introspector. Unfortunately, this change cannot be done by us (= NetBeans developers). It must be fixed by JDK team. I have reported this problem in their bug-tracking system and I am waiting for their response.

I just noticed that it's already fixed in OpenJDK jdk6 Mercurial forrest. Although very ugly fix (using synchronized map wrapper in addition), it should work. We just have to wait for an EA binary build then...

And what is next? Java release is u21!

Unfortunately the fix (already in OpenJDK forrest) did not get into JDK6u21 release. I'm running NB6.9 on an self-built OpenJDK for now...

???

*** Bug 188696 has been marked as a duplicate of this bug. ***

*** Bug 188784 has been marked as a duplicate of this bug. ***

*** Bug 188789 has been marked as a duplicate of this bug. ***

The corresponding JDK issue was fixed in JDK 7 development builds:
http://hg.openjdk.java.net/jdk7/jdk7-gate/jdk/rev/3dc686ecb4cd
The fix will be available since build 102.

Let's hope that it will appear soon also in JDK 6 update builds. Currently, the integration of the fix seems to be scheduled for JDK 6u23.

*** Bug 189460 has been marked as a duplicate of this bug. ***

*** Bug 189257 has been marked as a duplicate of this bug. ***

*** Bug 189849 has been marked as a duplicate of this bug. ***

*** Bug 189926 has been marked as a duplicate of this bug. ***

*** Bug 189856 has been marked as a duplicate of this bug. ***

*** Bug 189659 has been marked as a duplicate of this bug. ***

*** Bug 190039 has been marked as a duplicate of this bug. ***

Deadlock Zoom:
Found one Java-level deadlock:
=============================
"GUI Builder":
  waiting to lock monitor 103123eb0 (object 1071058e0, a java.lang.Class),
  which is held by "AWT-EventQueue-1"
"AWT-EventQueue-1":
  waiting to lock monitor 103124000 (object 1132776a8, a java.lang.Object),
  which is held by "GUI Builder"

Java stack information for the threads listed above:
===================================================
"GUI Builder":
	at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:426)
	- waiting to lock <1071058e0> (a java.lang.Class for java.beans.Introspector)
	at java.beans.Introspector.<init>(Introspector.java:377)
	at java.beans.Introspector.getBeanInfo(Introspector.java:164)
	- locked <1132776a8> (a java.lang.Object)
	at java.beans.Introspector.getBeanInfo(Introspector.java:227)
	at java.beans.Introspector.<init>(Introspector.java:386)
	at java.beans.Introspector.getBeanInfo(Introspector.java:164)
	- locked <1132776a8> (a java.lang.Object)
	at org.openide.util.Utilities.getBeanInfo(Utilities.java:426)
	at org.netbeans.modules.form.FormUtils.getBeanInfo(FormUtils.java:1771)
	at org.netbeans.modules.form.palette.PaletteItem.getBeanDescriptor(PaletteItem.java:296)
	at org.netbeans.modules.form.palette.PaletteItem.getDisplayName(PaletteItem.java:227)
	at org.netbeans.modules.form.palette.PaletteItemDataObject$ItemNode.getDisplayName(PaletteItemDataObject.java:323)
	at org.openide.nodes.FilterNode.getDisplayName(FilterNode.java:533)
	at org.openide.nodes.FilterNode.getDisplayName(FilterNode.java:533)
	at org.netbeans.modules.form.palette.PaletteUtils$1.run(PaletteUtils.java:242)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1957)
"AWT-EventQueue-1":
	at java.beans.Introspector.getBeanInfo(Introspector.java:157)
	- waiting to lock <1132776a8> (a java.lang.Object)
	at org.openide.util.Utilities.getBeanInfo(Utilities.java:426)
	at org.netbeans.modules.form.FormUtils.canBeContainer(FormUtils.java:1055)
	at org.netbeans.modules.form.FormUtils.isContainer(FormUtils.java:1000)
	at org.netbeans.modules.form.FormModel.setFormBaseClass(FormModel.java:147)
	at org.netbeans.modules.form.GandalfPersistenceManager.loadForm(GandalfPersistenceManager.java:424)
	at org.netbeans.modules.form.GandalfPersistenceManager.loadForm(GandalfPersistenceManager.java:298)
	- locked <137312b80> (a org.netbeans.modules.form.GandalfPersistenceManager)
	at org.netbeans.modules.form.FormEditor$3.run(FormEditor.java:336)
	at org.netbeans.modules.form.FormLAF$2.run(FormLAF.java:293)
	- locked <113f282f0> (a javax.swing.MultiUIDefaults)
	- locked <1071058e0> (a java.lang.Class for java.beans.Introspector)
	at org.openide.util.Mutex.doEventAccess(Mutex.java:1361)
	at org.openide.util.Mutex.readAccess(Mutex.java:320)
	at org.netbeans.modules.form.FormLAF.executeWithLookAndFeel(FormLAF.java:276)
	at org.netbeans.modules.form.FormEditor.loadFormData(FormEditor.java:333)
	at org.netbeans.modules.form.FormEditor.loadFormDesigner(FormEditor.java:231)
	at org.netbeans.modules.form.FormDesigner.finishComponentShowing(FormDesigner.java:1897)
	at org.netbeans.modules.form.FormDesigner.access$1100(FormDesigner.java:107)
	at org.netbeans.modules.form.FormDesigner$PreLoadTask$1.run(FormDesigner.java:1862)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:137)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Found 1 deadlock.

Can I just somehow disable the palette, as it seems to be related to the deadlock?
How do I tell netbeans to NOT open it when opening a GUI form?

*** Bug 190489 has been marked as a duplicate of this bug. ***

*** Bug 190649 has been marked as a duplicate of this bug. ***

Tested with Netbeans 6.9.1 and just released JDK 1.6.0_20 - bug still here.

From thread dump:

2010-10-13 20:56:11
Full thread dump Java HotSpot(TM) Client VM (17.1-b03 mixed mode, sharing):

...

Found one Java-level deadlock:
=============================
"GUI Builder":
  waiting to lock monitor 0xb34a8308 (object 0x865fef70, a java.lang.Class),
  which is held by "AWT-EventQueue-1"
"AWT-EventQueue-1":
  waiting to lock monitor 0x0918c9f4 (object 0x76aef028, a java.lang.Object),
  which is held by "GUI Builder"

Java stack information for the threads listed above:
===================================================
"GUI Builder":
	at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:426)
	- waiting to lock <0x865fef70> (a java.lang.Class for java.beans.Introspector)
	at java.beans.Introspector.<init>(Introspector.java:377)
	at java.beans.Introspector.getBeanInfo(Introspector.java:164)
	- locked <0x76aef028> (a java.lang.Object)
	at org.openide.util.Utilities.getBeanInfo(Utilities.java:426)
	at org.netbeans.modules.form.FormUtils.getBeanInfo(FormUtils.java:1771)
	at org.netbeans.modules.form.palette.PaletteItem.getBeanDescriptor(PaletteItem.java:296)
	at org.netbeans.modules.form.palette.PaletteItem.getDisplayName(PaletteItem.java:227)
	at org.netbeans.modules.form.palette.PaletteItemDataObject$ItemNode.getDisplayName(PaletteItemDataObject.java:323)
	at org.openide.nodes.FilterNode.getDisplayName(FilterNode.java:533)
	at org.openide.nodes.FilterNode.getDisplayName(FilterNode.java:533)
	at org.netbeans.modules.form.palette.PaletteUtils$1.run(PaletteUtils.java:242)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1957)
"AWT-EventQueue-1":
	at java.beans.Introspector.getBeanInfo(Introspector.java:157)
	- waiting to lock <0x76aef028> (a java.lang.Object)
	at org.openide.util.Utilities.getBeanInfo(Utilities.java:426)
	at org.netbeans.modules.form.FormUtils.getBeanInfo(FormUtils.java:1771)
	at org.netbeans.modules.form.RADComponent.getBeanInfo(RADComponent.java:427)
	at org.netbeans.modules.form.RADComponent.initInstance(RADComponent.java:187)
	at org.netbeans.modules.form.FormModel.setFormBaseClass(FormModel.java:169)
	at org.netbeans.modules.form.GandalfPersistenceManager.loadForm(GandalfPersistenceManager.java:424)
	at org.netbeans.modules.form.GandalfPersistenceManager.loadForm(GandalfPersistenceManager.java:298)
	- locked <0x794f5718> (a org.netbeans.modules.form.GandalfPersistenceManager)
	at org.netbeans.modules.form.FormEditor$3.run(FormEditor.java:336)
	at org.netbeans.modules.form.FormLAF$2.run(FormLAF.java:293)
	- locked <0x7729d4d0> (a javax.swing.MultiUIDefaults)
	- locked <0x865fef70> (a java.lang.Class for java.beans.Introspector)
	at org.openide.util.Mutex.doEventAccess(Mutex.java:1361)
	at org.openide.util.Mutex.readAccess(Mutex.java:320)
	at org.netbeans.modules.form.FormLAF.executeWithLookAndFeel(FormLAF.java:276)
	at org.netbeans.modules.form.FormEditor.loadFormData(FormEditor.java:333)
	at org.netbeans.modules.form.FormEditor.loadFormDesigner(FormEditor.java:231)
	at org.netbeans.modules.form.FormDesigner.finishComponentShowing(FormDesigner.java:1897)
	at org.netbeans.modules.form.FormDesigner.access$1100(FormDesigner.java:107)
	at org.netbeans.modules.form.FormDesigner$PreLoadTask$1.run(FormDesigner.java:1862)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:137)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Found 1 deadlock.

"Tested with Netbeans 6.9.1 and just released JDK 1.6.0_20" - sorry, I mean 1.6.0_22.

As said in comment #20, the fix is expected in JDK 6u23. It's already reported as integrated, should appear in b02.

Tested with NetBeans 6.9 and an early access JDK 6u23 (build 1.6.0_23-ea-b03);  the bug seems to be solved.

(In reply to comment #35)
> Tested with NetBeans 6.9 and an early access JDK 6u23 (build 1.6.0_23-ea-b03); 
> the bug seems to be solved.

It works here too.

Closing as fixed beacause the corresponding JDK bugs were fixed:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6963811
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2194979
and the fix is available in JDK6u23 build 03.
You can download the latest early access build of JDK 6 at http://download.java.net/jdk6/

*** Bug 191115 has been marked as a duplicate of this bug. ***

Anyone an idea when JDK 6u23 is supposed to be released?

(In reply to comment #39)
> Anyone an idea when JDK 6u23 is supposed to be released?

It is not defined yet https://jdk6.dev.java.net/

*** Bug 191121 has been marked as a duplicate of this bug. ***

Currently only build 1.6.0_23-ea-b01 is publicly available. Where is b03? Hope we get a release date soon...

(In reply to comment #42)
> Currently only build 1.6.0_23-ea-b01 is publicly available. Where is b03? Hope
> we get a release date soon...

You can get b03 at http://download.java.net/jdk6/

Regards

Thank you. Fun that the official site points to https://jdk6.dev.java.net/6uNea.html and therefore b01 only...

*** Bug 191413 has been marked as a duplicate of this bug. ***

*** Bug 191514 has been marked as a duplicate of this bug. ***

I can also confirm fix running on Ubuntu 10.04.1 with NetBeans 6.9.1 with
java version "1.6.0_23-ea"
Java(TM) SE Runtime Environment (build 1.6.0_23-ea-b03)
Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode)

*** Bug 191768 has been marked as a duplicate of this bug. ***

The correct resolution is WONTFIX, the fix was done on JDKs side not in our code base.

What about us poor Mac OSX users?
Latest java for Mac is 6u22...
And no openjdk yet :-(

Don't upgrade yet or use a pre u20 Java release. Java 1.6u23 is not released yet. Currently, it is available in early access. I guess as soon as it will be released, we will get an update from Apple.

*** Bug 192070 has been marked as a duplicate of this bug. ***

:-) Unfortunately I've already upgraded.
So no netbeans for now...

@guyer
I had the same issue. I just took my timemachine backup and restored the /System/Library/Frameworks/JavaVM.framework like it was before the update. I made sure to keep the original file (upgraded one) to restore it when update 23 will be available. Hope Oracle is going to release it soon and Apple will follow...

Did you try resetting the palette (thus removing offensive components)?
The bug should not affect people with default palettes.

I can't reproduce it since I've downgraded, but I remember that resetting the palette didn't change anything, and the deadlock still occurred.

> I can't reproduce it since I've downgraded, but I remember that resetting
> the palette didn't change anything, and the deadlock still occurred. 

Yes, you are right. The deadlock happens even with the default content of the palette. I am not aware about any workaround for this deadlock and I doubt there is one (besides not using the problematic builds of JDK).

(In reply to comment #57)
> > I can't reproduce it since I've downgraded, but I remember that resetting
> > the palette didn't change anything, and the deadlock still occurred. 
> 
> Yes, you are right. The deadlock happens even with the default content of the
> palette. I am not aware about any workaround for this deadlock and I doubt
> there is one (besides not using the problematic builds of JDK).

I actually observed the problem with a default or disabled palette (and, by looking at the thread dump, I would say it's a problem of the form editor itself interacting with the Introspector).

Well, I am not sure why it is working for us here on 3 different apple machines. It deadlocsk 100% of the time if we have our components in the palette.
Resetting the palette would make Netbeans operate normally again.
I have no issues with Netbeans anymore, and here is the java version we are using:
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) Client VM (build 17.1-b03-307, mixed mode)

It is a mystery then. Glad it works for us though.

*** Bug 192211 has been marked as a duplicate of this bug. ***

*** Bug 192323 has been marked as a duplicate of this bug. ***

*** Bug 192272 has been marked as a duplicate of this bug. ***

*** Bug 192424 has been marked as a duplicate of this bug. ***

*** Bug 192369 has been marked as a duplicate of this bug. ***

*** Bug 192577 has been marked as a duplicate of this bug. ***

*** Bug 192615 has been marked as a duplicate of this bug. ***

Netbeans workaround

I ran into this problem last week and stumbled around and managed to get the forms to load. I do have a custom palette. It appears the deadlock is caused by loading a form that does not contain a bean from the custom palette. I load the source for a form/panel that contains a bean from the custom palette in source code mode. I then did a clean and build(not sure if this is needed). Then switch to the design view and the form and palette loads.

Probably other ways to achieve the same result but the key appears to be loading the form in source code view first. I am on OSX with the latest Java updates.

This is a JDK bug and the only work around is to use JDK <= 1.6.0_20 or JDK >= 1.6.0_23 b03 early access. The problem is with the Introspector().getBeanInfo() with the BEANINFO_CACHE lock held (see comment #3). I have been using NBs 6.9.1 on the early access JDK for a couple of weeks and have not experienced this problem since. NBs seems to be a little faster too!

(In reply to comment #69)
> This is a JDK bug and the only work around is to use JDK <= 1.6.0_20 or JDK >=
> 1.6.0_23 b03 early access. The problem is with the Introspector().getBeanInfo()
> with the BEANINFO_CACHE lock held (see comment #3). I have been using NBs 6.9.1
> on the early access JDK for a couple of weeks and have not experienced this
> problem since. NBs seems to be a little faster too!

I understand but for those of us on OSX we are stuck until Apple does a release with the fix. The path I mentioned appears to get around the initialization problem that causes the GUI to hang by loading source view first and then switching to design view. 

Typically I leave netbeans running so once it gets through the init problem everything works. Today I exited out of netbeans to get back memory for another application. When I started up netbeans to work on a swing panel in the gui designer I ran into the problem again. I went looking for a fix only to find out via this bug report I am stuck with it until Apple does an update.

It may be possible to change some ordering/initialization in the netbeans code to avoid the deadlock based on the way I am able to get it working.

(In reply to comment #70)
> (In reply to comment #69)
> > This is a JDK bug and the only work around is to use JDK <= 1.6.0_20 or JDK >=
> > 1.6.0_23 b03 early access. The problem is with the Introspector().getBeanInfo()
> > with the BEANINFO_CACHE lock held (see comment #3). I have been using NBs 6.9.1
> > on the early access JDK for a couple of weeks and have not experienced this
> > problem since. NBs seems to be a little faster too!
> 
> I understand but for those of us on OSX we are stuck until Apple does a release
> with the fix. The path I mentioned appears to get around the initialization
> problem that causes the GUI to hang by loading source view first and then
> switching to design view. 
> 
> Typically I leave netbeans running so once it gets through the init problem
> everything works. Today I exited out of netbeans to get back memory for another
> application. When I started up netbeans to work on a swing panel in the gui
> designer I ran into the problem again. I went looking for a fix only to find
> out via this bug report I am stuck with it until Apple does an update.
> 
> It may be possible to change some ordering/initialization in the netbeans code
> to avoid the deadlock based on the way I am able to get it working.

(In reply to comment #70)
> (In reply to comment #69)
> > This is a JDK bug and the only work around is to use JDK <= 1.6.0_20 or JDK >=
> > 1.6.0_23 b03 early access. The problem is with the Introspector().getBeanInfo()
> > with the BEANINFO_CACHE lock held (see comment #3). I have been using NBs 6.9.1
> > on the early access JDK for a couple of weeks and have not experienced this
> > problem since. NBs seems to be a little faster too!
> 
> I understand but for those of us on OSX we are stuck until Apple does a release
> with the fix. The path I mentioned appears to get around the initialization
> problem that causes the GUI to hang by loading source view first and then
> switching to design view. 
> 
> Typically I leave netbeans running so once it gets through the init problem
> everything works. Today I exited out of netbeans to get back memory for another
> application. When I started up netbeans to work on a swing panel in the gui
> designer I ran into the problem again. I went looking for a fix only to find
> out via this bug report I am stuck with it until Apple does an update.
> 
> It may be possible to change some ordering/initialization in the netbeans code
> to avoid the deadlock based on the way I am able to get it working.

I'm also a mac user, agree with willishf.  It should be much easier to update NB than mac JDK

Can NB team make a simple work-around?  This awful bug wastes me at least 1/5 working time developing GUIs on mac!

Being an all-apple shop, I vote +1 to try have Netbeans address this somehow by possibly forcing sequential load of the palette, GUI builder, and source view.
We have no idea when a new and corrected JDK will be released by Apple (especially now when they are so busy converting to OpenJDK process)

Great news: JDK u23 is available and the bug is fixed! Now I am eagerly waiting for Apple to release it too.

Of course available at: http://www.oracle.com/technetwork/java/javase/downloads/index.html

*** Bug 193173 has been marked as a duplicate of this bug. ***

*** Bug 193634 has been marked as a duplicate of this bug. ***

*** Bug 193829 has been marked as a duplicate of this bug. ***

It cannot be stressed enough how much Apple developers are left out in the cold on this issue.  With all the hullaballoo going on with respect to the future of Java support for Mac OS, there's no telling if or when we'll ever get Java 6 update 23.  So far, there is no expected or even tentative release date for the OpenJDK version that was announced by Oracle and Apple in November, 2010.

So, it seems Java developers on OS X have one of only a few less-than-ideal options:

1) Ensure you are only using the "stock" palette in NetBeans 6.9.  This makes things tough for people who are using custom component libraries (such as SwingX) or are developing applications on the NetBeans platform.
2) Downgrade to a previous version of NetBeans (such as 6.8).  
3) Switch to a different development platform.  This isn't practical for a lot of people, I would think.

I agree that it is ultimately the responsibility of the JVM developers/maintainers to fix the underlying problem.  However, I have cast my vote for this issue because of the situation that Apple users now find themselves in, because we find ourselves stuck between a rock and a hard place.

Dear fellow Java developers on Mac OS X, don't worry any more. I had the same concern, but I got a response from Apple: yes, there is a new Java update in preparation which will update Java 1.6 to u23. You can get an early preview at https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20748
Our long wait is almost over. Thank you Apple's Java dev team!

*** Bug 194278 has been marked as a duplicate of this bug. ***

*** Bug 193730 has been marked as a duplicate of this bug. ***

Please consider re-opening... still happens on IDE ver. 6.9.1 with JDK u23.
After I first installed the new JDK the bug seemed to be gone, but now it's back, and worse.I can't open any form at all.

I would be glad to attach a log, but I have no Idea where I find log files for netbeans...

If you see a deadlock on JDK6u23, please make a thread dump and attach it here.
http://wiki.netbeans.org/GenerateThreadDump

*** Bug 194828 has been marked as a duplicate of this bug. ***

*** Bug 194649 has been marked as a duplicate of this bug. ***

*** Bug 194158 has been marked as a duplicate of this bug. ***

*** Bug 194054 has been marked as a duplicate of this bug. ***

*** Bug 195343 has been marked as a duplicate of this bug. ***

*** Bug 194078 has been marked as a duplicate of this bug. ***

*** Bug 196058 has been marked as a duplicate of this bug. ***

*** Bug 198906 has been marked as a duplicate of this bug. ***

Fixed in 7(b102), 6u23(b02)

*** Bug 198578 has been marked as a duplicate of this bug. ***