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.
I installed the new 3.6 release candidate (RC2), and ran it with the "--laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel" switch to use the JDK's (Sun's JDK 1.4.2_04) GTK l&f. In the Options window (the text of which has the wrong background colour in the tree panel) I went to the Editor Settings for the Java Editor. On clicking the button for the Fonts & Colors setting I received the NPE listed below. Judging by the stack trace, this is a similar problem to issue 41676. java.lang.NullPointerException at org.netbeans.modules.editor.options.ColoringArrayEditorPanel.addPropertyChangeListener(ColoringArrayEditorPanel.java:184) at com.sun.java.swing.plaf.gtk.SynthPanelUI.installListeners(SynthPanelUI.java:48) at com.sun.java.swing.plaf.gtk.SynthPanelUI.installUI(SynthPanelUI.java:36) at javax.swing.JComponent.setUI(JComponent.java:449) at javax.swing.JPanel.setUI(JPanel.java:131) at javax.swing.JPanel.updateUI(JPanel.java:104) at javax.swing.JPanel.<init>(JPanel.java:64) at javax.swing.JPanel.<init>(JPanel.java:87) at javax.swing.JPanel.<init>(JPanel.java:95) at org.netbeans.modules.editor.options.ColoringArrayEditorPanel.<init>(ColoringArrayEditorPanel.java:68) at org.netbeans.modules.editor.options.ColoringArrayEditor.getCustomEditor(ColoringArrayEditor.java:52) at org.openide.explorer.propertysheet.PropertyDialogManager.<init>(PropertyDialogManager.java:108) at org.openide.explorer.propertysheet.CustomEditorAction.actionPerformed(CustomEditorAction.java:174) at org.openide.explorer.propertysheet.SheetTable.processMouseEvent(SheetTable.java:560) at java.awt.Component.processEvent(Component.java:4897) at java.awt.Container.processEvent(Container.java:1569) at java.awt.Component.dispatchEventImpl(Component.java:3615) at java.awt.Container.dispatchEventImpl(Container.java:1627) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3195) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128) at java.awt.Container.dispatchEventImpl(Container.java:1613) at java.awt.Window.dispatchEventImpl(Window.java:1606) at java.awt.Component.dispatchEvent(Component.java:3477) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:456) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
I'm working now on GTK support for 4.0, and have filed a host of bugs against the JDK regarding problems in it. This particular one is fixed in the latest internal builds of 1.5.0, but not fixed in 1.4.2 or in the currently released beta. GTK L&F in 1.4.2 will never be supported for NetBeans (unless fixes for various bugs are backported to some future maintenance release). It is too buggy. Don't use it. NetBeans 4.0 + JDK 1.5 will default to GTK look and feel on Linux, and should look and work nicely. I will make sure this problem is not reproducible on 1.5
Passing property editor issues to new owner, Jirka
See at issue 41676 for know-how how to fix it and also for issue's background. Quoted from issue 41676: ------- Additional Comments From Tim Boudreau 2004-04-06 15:24 PDT ------- Martin, I just had a similar issue reported. Is this problem because the JDK is adding listeners on a non AWT thread, or because you're constructing a component on some other thread? If the look and feel is doing it on a different thread, we should file a high priority bug for it to be fixed in the JDK. BTW, do *not* believe the advice that it is *ever* safe to even construct a Swing component on a non AWT thread. It is not true, unless the entire application has not yet shown any GUI. Swing component constructors call updateUI(). The look and feel can then do *anything* it wants, and frequently it will want to grab the AWT tree lock. We have about 20 deadlocks in our bug history due to exactly that. Do not *ever* construct Swing components on any thread except the AWT thread. It is not safe, and the conventional advice that it is is simply wrong for anything except toy applications.
I think the problem here is not a threading but a wrong design. The ColoringArrayEditorPanel defines add/removePropertyChangeListener() methods (manages its own PropertyChangeSupport instance stored in "support" variable). However as ColoringArrayEditorPanel extends JPanel and therefore JComponent.add/removePropertyChangeListener() existing methods get overriden in ColoringArrayEditorPanel. As "support" variable gets populated in ColoringArrayEditorPanel's constructor then if any of the super constructors call add/removePropertyChangeListener() (which GTKLookAndFeel does but legally) then it will certainly fail as the "support" variable is still not initialized. The issue 41676 suffers from the same problem. I did not write ColoringArrayEditorPanel code but I did not find any reason why not to use the default property change support handling from the JComponent. I've tried to just remove our extra handling and everything seems to work fine including validation tests so I'm going to commit the change. Fixed in trunk: Checking in src/org/netbeans/modules/editor/options/ColoringArrayEditorPanel.java; /cvs/editor/src/org/netbeans/modules/editor/options/ColoringArrayEditorPanel.java,v <-- ColoringArrayEditorPanel.java new revision: 1.26; previous revision: 1.25
*** Issue 42867 has been marked as a duplicate of this issue. ***
verified in [nb_dev](200407281800)