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.
200401061900, jdk1.4.2 start with fresh userdir, unmount sampledir try mount Local dir by popup on Filesystem -> NPE appears -I'm not sure who to assigned, NPE changes during a few attempts
Created attachment 12738 [details] ide.log
:( have to add RANDOM keyword, I was able to reproduce about 3-4 times and I'm not able to do it now...
I've seen this at home too. I think it's simply a Windows L&F JFileChooser problem - the first NPE is JFileChooser calling new ImageIcon(null). Windows XP look and feel somehow tries to get bitmaps of buttons and things using, I think, some native code. It looks like some kind of timing problem - the bitmap hasn't been prepared or something like that for one of their buttons. The second stack trace, in PropertyPanel looks like a side-effect of the first one - the exception happened when its inner component was being created, so the inner component is null, but the property panel doesn't test if the inner component is null (because it can't be unless something like this happened). It seems to happen for me only the first time a JFileChooser is shown in a session. Maybe there's some warmup-type workaround that would make sure the file chooser UI was properly loaded...
it's really ugly and happens really often. User cannot mount anything after that. -workaround to mount something - use "File | Open File"
*** Issue 37822 has been marked as a duplicate of this issue. ***
beaninfo.editors.FileEditor plays with JFileChooser and somehow hacks them (see at createHackedFileChooser()), I guess there is a right place to intervene.
I suppose. The only thing it does is add/remove things from the file choosers actionmap - what we're talking about is a little more radical. Jirka, when this action runs, is there any possibility the filechooser is getting created on some strange thread? I could easily believe that would cause such problems.
Well, I can put some test for the NPE in createHackedFileChooser, and just make it try again...
Worked around in trunk. I added a test for the NPE and simply try to create the file chooser again if caught. Second creation of a JFileChooser succeeds, so I can't reproduce the problem anymore. FYI, this bug has nothing to do with our hacking file choosers - it occurs in the constructor for JFileChooser before we do anything to touch it. It is also not threading related - the file chooser is constructed on the event thread. The bug is in the XP L&F file chooser UI, which calls new ImageIcon(null). I will file a JDK bug on it. /cvs/core/src/org/netbeans/beaninfo/editors/FileEditor.java,v <-- FileEditor.java new revision: 1.28; previous revision: 1.27
verified
*** Issue 42498 has been marked as a duplicate of this issue. ***
Posted on nbusers today: ---- I've tried both with netbeans 3.6 and 4.0, when I do something that requires a file chooser (mounting etc) I get this (the specific trace is from a "mount local directory"): ---- It is the same stack trace as this bug - race condition in WindowsFileChooserUI on 1.4.2_05. I've beefed up the original fix in FileEditor, but there are other usages of JFileChooser in NetBeans which will have the same problem. Simply trying again works to fix it, but since the user is reporting the problem from FileEditor with the workaround in place, it may be necessary to try more than once. I will attach what I think is a better workaround - if 1.4 and windows, create an offscreen JFileChooser, catching the exceptions until it succeeds, failing over to globally use MetalFileChooserUI if it fails several times. I am sending a build of core with the workaround to the user who is reproducing the problem.
Created attachment 17166 [details] Patch to exercise WindowsFileChooserUI during startup
Workaround in trunk - as part of warmup, WindowsFileChooserUI will be exercised (and exceptions caught), so that its icons will already be loaded before any file chooser is actually shown to the user. In the case that it completely fails, it will fallback to use MetalFileChooserUI, so the IDE is never left unusable. Checking in src/org/netbeans/beaninfo/editors/FileEditor.java; /cvs/core/src/org/netbeans/beaninfo/editors/FileEditor.java,v <-- FileEditor.java new revision: 1.33; previous revision: 1.32 done Processing log script arguments... More commits to come... RCS file: /cvs/core/src/org/netbeans/core/Issue38479Workaround.java,v done Checking in src/org/netbeans/core/Issue38479Workaround.java; /cvs/core/src/org/netbeans/core/Issue38479Workaround.java,v <-- Issue38479Workaround.java initial revision: 1.1 done Checking in src/org/netbeans/core/WarmUpSupport.java; /cvs/core/src/org/netbeans/core/WarmUpSupport.java,v <-- WarmUpSupport.java new revision: 1.4; previous revision: 1.3 done
*** Issue 48199 has been marked as a duplicate of this issue. ***
Closed
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4711700 should be the reason. OTOH it says that it was fixed for 1.4.2_04 but Tim added a note that it was failing on 1.4.2_05 too