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.
Despite its documentation to the contrary, as well as its behavior in version 3.4, the Utilities.showJFileChooser() method does NOT allow null to be passed as the parent parameter. The problem lies in the following change to the Utilities class: OpenAPI 3.4: 1385 dialog.setLocationRelativeTo(parent); OpenAPI 3.5: 1572 dialog.setBounds(findCenterBounds (parent.getGraphicsConfiguration(), 1573 dialog.getSize())); The latter version dereferences the "parent" variable without compensating for a null parent and causes a NullPointerRxception. Note that the OpenAPI documentation and JFileChooser itself allows for a null parent component parameter. This problem affects OpenAPI 3.5 and 3.5.1.
Reassiging to Utilities/Openfile.
Reassigning back to OpenIDE as the method in question is org.openide.util.Utilities.showJFileChooser(...) which is not a part of the Utilities *module*.
1.It is already deprecated in current main trunk. (Not in NB 3.5 because it was needed for JDK 1.3). 2.There is no explicit note that parent CAN BE null. It means that it CANNOT BE null according to NB convention. So there is not problem between doc and behaviour. The only problem could be inconsistency with JFileChooser.showDialog which DOES allow null as parent. (And it is explicitely noted in javadoc.) Conclusion: There is change in behaviour BUT it was not documented that parent can be null so if you depend on it it is wrong.
If it is important for you as workaround use main window as parent. (Or window parent of currently active component. You can get main window using Winsys API WindowManager. You can find window parent using SwingUtilities.getWindowAncestor - more appropriate for SDI where you probably want to set current window as owner of dialog.)
We have already worked around the problem, but keep in mind that you cannot use the main window as the parent because that causes the dialog to appear at the top of the screen instead of centered in the middle. The only way to center the dialog is to either take complete manual control of its position (a pain), or as is normal with Swing, just provide a null parent. I disagree that this behavior is "correct" despite the Netbeans convention (of which I'm sure most module developers are unaware). Since it used to work with a null parent in previous versions, and worked in a way that is completely congruent with any Swing developer's expectation, I think it is very reasonable for developers to expect null to work here. It is no longer an issue for our module, but I urge you to at least make a note in the documentation to indicate that null is not allowed despite the competing Swing convention, and also put a null check at the top of the method if that really is the intent. However, I really suggest just adding the null check in the body of the method and making the method behave as it did in 3.4, especially if the method is now deprecated.
I can fix it. If I am right mentioned code tries to center JFileChooser in respect to parent. If parent is null I could center it in respect to screen. What I wanted to say: It is common convention - If parameter can be null it should be explicitely noted in javadoc. => If it is not noted parameter CANNOT BE null. It means that there is no problem with javadoc and behaviour. I agree that behaviour is not consistent with Swing. JFileChooser, JDialog where parent or owner can be null. (Again as you can see it is explicitely documented.) In any case I cannot fix it for NB 3.5 or 3.5.1. It is too late. I will fix to current main trunk.
Jesse when I change this shall I update apichanges as usual? Utilities.showJFileChooser() is deprecated now.
Doesn't matter if it is deprecated, it is still an API change if you permit null. Why not just close this as WONTFIX anyway? It is, after all, deprecated. Unless you plan to release some 3.5.x update release with a fix. Todd - no parameter nor return value may be null unless explicitly permitted. This is documented in the Open APIs, and has been for a long time: http://www.netbeans.org/community/guidelines/code-conventions.html
Ok. Marking as WONTFIX. It is deprecated and as replacement JFileChooser methods should be directly used with JDK 1.4.
Jesse, I am fine with not doing anything about it since our particular issue has been resolved. I'm just saying that in this particular case, naive developer's expectations are too easily based on Swing conventions, which dictate that null would be acceptable here. Swing conventions override Netbeans conventions in my mind, as Swing is the more fundamental; when I used null in this call, I had no inkling that it might not be acceptable given the way Swing works. I'm just suggesting that at minimum the documentation *in this case* needs to be more explicit because of the conflicting convention. Thanks.
True, it would be better for such methods that have a close alignment with an existing API to be more explicit.
closed