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.
Summary: | "Add NetBeans Platform" broken on Mac OS X | ||
---|---|---|---|
Product: | apisupport | Reporter: | lordy <lordy> |
Component: | Project | Assignee: | Martin Krauskopf <mkrauskopf> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | rmatous |
Priority: | P1 | ||
Version: | 5.x | ||
Hardware: | Macintosh | ||
OS: | Mac OS X | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | NullPointerException |
Description
lordy
2006-03-01 09:45:37 UTC
Created attachment 29061 [details]
NullPointerException
Related to filesystems on MacOS. Did version 5.0u2 mean that this bug find his why into u1 and get fixed in u2? If so i think that is not good idea. Better go back to no FileUtil.normalizeFile or to a if(!isMac) solution. I don't know if this bug is in 50u1. 50u1 is on the branch. The 50u2 is dev build. If it is on 50u1 we will fix it I hope. 50u1 is on the branch. The 50u2 is dev build. Yes it it is reproducible on 5.0u1. Thanks a lot. Thanks for the nice analysis. I think we already had a similar bug with the FileChooser on MacOS. I'll take a look at it soon. Does this happen everytime? File chooser on MacOS returns null from platformChooser.getSelectedFile() after FileChooser.SELECTED_FILE_CHANGED_PROPERTY is fired. According to JFileChooser's source in Sun's JDK it is presumably OK to retrun null from JFC.gSF(). But not sure if there is some javadoc/spec if it is legal to return null after the property is fired - seems ok to me. So I've just added check for null. Please let me know (lordy or zajo) if it helps. I'll backport then. Checking in PlatformChooserVisualPanel.java; new revision: 1.16; previous revision: 1.15 verified revision 1.16 Thanks. Backported. ui/platform/PlatformChooserVisualPanel.java; 1.15 -> 1.15.2.1; |