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: | NPE from BasicInternalFrameTitlePane.addSystemMenuItems under JDK 1.3 | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Window System | Assignee: | _ tboudreau <tboudreau> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | dnoyeb |
Priority: | P1 | Keywords: | JDK_SPECIFIC |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Stack trace |
Description
Jesse Glick
2003-02-03 15:23:38 UTC
Created attachment 8767 [details]
Stack trace
Note that this exception has been thrown repeatedly during the projects continuous build, causing it to fail. Fixed in trunk. Please don't forget to: - set target milestone when fixing - include info on affected files (at least NbInternalFrameUI.java 1.5) - give a better change log comment than: Fix to issue 30606 which will be useless to anyone reading the log for this file later unless they go running to IZ; suggest more like #30606: NPE during startup under JDK 1.3 from addSystemMenuItems i get same error in dev build 200302030100 jdk 1.3.1_06 But I do not get it when I start with WindowsLookAndFeel. If I try starting without WLF I get the NPE. Please try in the next published dev build, which should have the fix. It still fails (at least in projects build and on my machine). I have latest sources of core and openide from main trunk. I checked in a fix for this last night - overriding addSystemMenuItems in NbTitlePane, so an NPE can't possibly be being thrown there. Tested it on JDK 1.3 & 1.4 and everything was fine. Are you getting a different exception? Have you done a CVS update this morning? The class in question is org.netbeans.core.windows.frames.NbInternalFrameUI$NbTitlePane (I should have never done the favor to QA and switched this back to subclassing BasicInternalFrameTitlePane - none of this would be happening now!) My apologies, the method signature on the fix from last night was not accurate. Fixed now. Dont some languages have a flag you can add that says this is an override, and if its determined to not be one at compile time, a compiler error is thrown? might be a nice optional feature, but I know it wouldnt solve every problem. verified in [nb_dev](20030227) |