This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
To reproduce this do the following: 1. Create a simple swing application 2. Create a new form and place some swing components in there 3. Add from the palette the java bean "jFXPanel" to the layout 4. Resize the panel in GUI editor 5. Save form 6. close form 7. Re-open form 8. Netbeans shows an empty gui editor and freezes totally
Summary: In order to make javafx.embed.swing.JFXPanel usable in NetBeans (including GUI builder) there should be the jfxrt.jar on the boot classpath - just like other parts of the JDK. If the JavaFX classes are not on the boot claspath, the GUI builder loads them via the project classloader (from project classpath) like if their were project specific classes. That means it can load more versions of the same classes - and the multiple occurrences cause problems. JFXPanel makes calls to PlatformImpl which requires the "JavaFX application" be started, waiting on that. But it seems that only the first version of the loaded PlatformImpl class actually gets to the state of a started app. The other just hang (see the stack trace below). I don't understand all the details, but is apparent that the JavaFX platform is not designed for such use. It should be loaded just once and so be on the application (boot) classpath. It is the case for any application that uses JavaFX, just not for NetBeans - it does not use it. In such case we can't instantiate JFXPanel in NetBeans either. If really want to have GUI forms with JFXPanel, a possible workaround could be to add the jfxrt.jar manually, so e.g. by adding an additional switch to netbeans.etc file (to netbeans_default_options property): -J-Xbootclasspath/a:path_to_jfxrt.jar_under_jdk The hang: "AWT-EventQueue-0" prio=6 tid=0x000000000b99f000 nid=0xd1c waiting on condition [0x000000000fa0d000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f717f340> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:8 34) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer .java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.j ava:1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at com.sun.javafx.application.PlatformImpl.waitForStart(PlatformImpl.java:138) at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:159) at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:150) at javafx.application.Platform.runLater(Platform.java:52) at javafx.embed.swing.JFXPanel.addNotify(JFXPanel.java:673) ...
This problem appears to be fixed in JDK 1.8.0 (since EA build 75) where jfxrt.jar was moved from the lib folder to lib/ext and so appears on application classpath then: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003171 I've tried it on JDK 1.8.0-ea-b103 and it works fine. Don't know if the move from lib to lib/ext will be done for some JDK 7, it's an incompatible change after all. At this moment it is not changed in update 25.
Made a fix that refuses to load JavaFX classes from a project, this should prevent the hang (JFXPanel class will not even load): http://hg.netbeans.org/jet-main/rev/51f06f6a7ba6 Would probably be good to have it in NB 7.4.
Test case: 1) Create a JavaFX application. 2) Create a JFrame form in it. 3) With the GUI form opened on Design, click in palette on Beans > Choose Bean, enter javafx.embed.swing.JFXPanel. 4) Move mouse over the form and add the panel. 5) Save the form, close and open again. Now if on JDK 8 (or when having jfxrt.jar on boot classpath), all the steps above should work, no hang or error should appear. (Better try to repeat closing/opening the form with the panel a few times, or create yet another form, etc). On JDK 7 before the fix the steps led to hanged IDE, usually already in the first reopening. On JDK 7 after the fix, it should fail in step 4 complaining that the class can't be loaded. This is correct behavior, the class should not be available in this case.
Transplanted to release74: http://hg.netbeans.org/releases/rev/e854ef726b1c