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.
[release35-200304062350, Sun JDK 1.4.2-beta, MDI] Just started with a clean userdir and got a bunch of exceptions (full exception stack-trace will be attached): Annotation: Could not work with top component reference Windows/WindowManager/Editing/explorer/properties.wstcref and update its mode, reason: Wrong settings format. Annotation: Source: Windows/Components/properties.settings ... java.io.IOException: Wrong settings format. at org.netbeans.modules.settings.convertors.XMLSettingsSupport$SettingsRecognizer.createFromMethod(XMLSettingsSupport.java:643) ... ==> java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.netbeans.modules.settings.convertors.XMLSettingsSupport$SettingsRecognizer.createFromMethod(XMLSettingsSupport.java:640) ... Caused by: java.lang.ClassCastException at org.openide.awt.ToolbarButtonUI.installUI(ToolbarButtonUI.java:67) at javax.swing.JComponent.setUI(JComponent.java:449) ... ==> java.lang.ClassCastException at org.openide.awt.ToolbarButtonUI.installUI(ToolbarButtonUI.java:67) at javax.swing.JComponent.setUI(JComponent.java:449) at org.openide.awt.ToolbarToggleButton.updateUI(ToolbarToggleButton.java:63) ...
Created attachment 9733 [details] Exception stack-trace
I will attach patch with logging. Add patch to lib/patches. Please test it with command line switch -J-Dnetbeans.logger.console=true (in NB 3.5).
Created attachment 9742 [details] Patch
Created attachment 9743 [details] Console output produced w/ patch.
Please see my previous attachment. Hope it's what you need.
It looks like bug in our code namely ToolbarButtonUI: We use: ImageIcon icon = (ImageIcon)button.getDisabledIcon(); But AbstractButton returns Icon (interface implemented also by class ImageIcon) but in this case javax.swing.plaf.IconUIResource is returned by AbstractButton. Assigning to openide/awt.
Tim, is it possible to fix it for 3.5 release ? (not 3.5 Beta) Without fixing this issue, IDE is useless on Windows with Win L&F.
*** Issue 32674 has been marked as a duplicate of this issue. ***
Created attachment 9769 [details] Patch to use a BufferedImage in the case the returned icon is not ImageIcon
Created attachment 9770 [details] Binary patch - Mariane, can you test?
I've tried your patch and NPE rises (see attached stack trace). :(
Created attachment 9772 [details] NullPointerException
Looks like UIManager.getIcon() is returning null for this in addition. The patch should be kept, since it is wrong for our code to assume the Icon from UIManager will be an instance of ImageIcon. I'll add another patch which tests for null and throws an NPE with an intelligent enough message to try to figure out what icon UIManager returned null for.
Created attachment 9773 [details] Same patch, but with fail-fast NPE w/ better message
Created attachment 9774 [details] Same as above, binary version
Marian found an open JDK bug - JButton.getDisabledIcon() returns null if getIcon() returns an instanceof Icon, not ImageIcon. So we get an NPE on Windows instead of a CCE. Attaching yet another patch, that attempts to fall back to getIcon() if getDisabledIcon() returns null.
Created attachment 9780 [details] Patch including fallback to getIcon and fail-fast NPE
Created attachment 9781 [details] Binary version w/ fallback to getIcon
Just for note: http://developer.java.sun.com/developer/bugParade/bugs/4820053.html
Looks like the problem for the rest of the toolbars is that ToolbarButton does not call super.updateUI() when it overrides updateUI(). The whole ToolbarButton/ToolbarButtonUI thing is a mess. ToolbarButtonUI contains code to create a "grayed out" icon (in a needlessly complex manner). So does ToolbarButton. I am mystified at what the point of ToolbarButtonUI ever is or was. Most of its history was drowned by the reformatting before we open-sourced NetBeans. As far as I can tell, ToolbarButtonUI can be safely deleted in its entirety, and that will solve the problem on 1.4.2. I'm removing the use of ToolbarButtonUI. This will fix the toolbar buttons. If we want to port this fix to NetBeans 3.5, we will need test it on 1.3 and see if ToolbarButtonUI serves some purpose there - in which case we can test for 1.3 and use it. I'm leaving ToolbarButtonUI in the trunk for now, for that reason.
Tim, can you attach patch here :) Thanks ...
Created attachment 9798 [details] Yet another binary patch, this one eliminating the UI class completely
Waw, Tim great, it seems like it is fixed now, issue 32688 is fixed too :). I am going to test it with another L&Fs and different JDKs.
I reviewed the changes and I approve, fix is safe. Fix basically removes the code which caused the bug. Code in ToolbarButtonUI was probably workaround for missing feature of win LF on jdk 1.2 or older, now is obsolete.
approved for 3.5
I forgot - patch verified :)
*** Issue 32688 has been marked as a duplicate of this issue. ***
verified in [nb3.5](200304102350)
*** Issue 32861 has been marked as a duplicate of this issue. ***
*** Issue 33066 has been marked as a duplicate of this issue. ***