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.
There's an error in openide.loaders/src/org/openide/awt/MenuBar.java lines 274-277: Having no cause set is determined by t.getCausse() = t, not t.getCause() = null. ClassNotFoundException sets the cause to null (which is, of course, different to the throwable t itself), thus forbidding to set the cause. This bug is causing #138546. The "correct" error is hidden by this bug, thus making it impossible to find out what has caused the exception.
Thanks for finding, passing to data systems component owner.
Probably it's a JDK 1.6+ issue, haven't checked ClassNotFoundException implementation in JDK 1.5.
Please replace line 275 with: if (t instanceOf ClassNotFoundException) { newEx = new ClassNotFoundException(t.getMessage(), ex); newEx.setStackTrace(t.getStackTrace()); } else { t.initCause(ex); // Your "old" line 275 } Please note: This is untested code (haven't got the resources to test it myself)!
IMHO, Netbeans must not be released with this bug - it hides the ClassNotFoundException and makes looking for the cause of other suspicious exceptions (popping up from time to time, thus not possible to debug) impossible. So, as a result of this bug, NB looks instable.
This is not end IDE user P1! It maybe high priority bug from a point of user of the NetBeans Platform, however I doubt it is P1 even in this situation.
Sorry, not a P1.
The problem is, that there are sometimes more, sometimes less exceptions of this type, which hide probably several others, which cannot be fixed due to wrong error message and stack trace. Thus, correction of this bug is a precondition to find and fix those bugs. As these exceptions pop up again and again, without any sense, needing two passes to be fixed (one pass for this bug, a second one after getting the correct messages), I'd say the IDE isn't ready for release as long as this bug hasn't been fixed. Moreover, I've located the problem for You, so discussion should probably not be, if this is P1 or P2, as it should be possible to fix this within 5 minutes.
NB survived 2 years with this code. I really don't know how it affects end users. Thank you for your contribution, it will be used in trunk probably. Not a stopper from QE point of view (not user one) decreasing the priority
The problem is, that the bug obviously hides some others - as long as there's no problem, there's no ClassNotFoundException here, and no bad message etc.. And, the bug seems to be a result from modifications in JDK1.6.
I really do understand your concern however this is really harmless for end user. I'm against another fix in 6.5 even if the fix looks safe. It could destabilize the release. This bug should be fixed but not for 6.5.
That will just result in some more patches, as it will popup if more users use 6.5, i.e. if it is declared final - IMHO hiding bugs by others is a dangerous thing.
b52bd8327a6e
Integrated into 'main-golden', will be available in build *200810270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/b52bd8327a6e User: Jaroslav Tulach <jtulach@netbeans.org> Log: #150969: Making sure CNF is not swallowed