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.
In order to be able to implement issue #89558 we need an API for breakpoint validity. org.netbeans.api.debugger.Breakpoint can be in three statii: - unknown (the breakpoint is set by the user, but it's not yet submitted into the target debuggee) - valid (the breakpoint is successfully submitted into the debuggee) - invalid (the breakpoint is on an invalid location, or it was not possible to submit it into the debuggee due to some error) In case of invalid breakpoints, we need to inform the user about the reason.
Created attachment 38771 [details] The proposed API change & test.
Please review this simple & compatible API addition. Thanks.
some questions: - why not use Java enums for validity? Then you can get "static" typechecking and do away with IllegalArgumentException. - I'm assuming that the validity message will appear in the tip, so ... What is the interaction between validityMessage() and getSummary()? some concerns - As another client of this api I have a concern that I'm not in a position to verify through prototyping if this API will work for me. On the surface it looks reasonable but you never know until you try. I also understand that just because _my_ organization is unable to sync up with NB for some reason that NB should not be prevented from going ahead.
Ivan, thanks for the comments. It's true that enum is much better here, I'll update the diff. What do you mean by getSummary()? Don't you mean getPrintText()? That's just JPDA API and it's used for other purpose. In debuggercore there is no suitable method for that. It's true that it will be displayed in the tooltip and also a warning will be printed into debugger console for invalid breakpoints. I suppose that this API should be usable for other debuggers as well. I tried to make it general enough, but I can not predict demands of other debuggers. If you will find it insufficient later, we can either add more validity values or extend the API in some other way according to concrete demands.
getSummary() == NodeModel.getShortDescription() I there exists a non-null validityMessage who wins in the race for the tooltip? the validity message or getShortDescription()?
Created attachment 38880 [details] A new proposed API change & test.
NodeModel.getShortDescription() is a different part of the code. In JPDA we'll return Breakpoint.getValidityMessage() in NodeModel.getShortDescription() (besides other description). It's in different modules, therefore we need to have it in the API to be able to transfer the invalid message from implementation module (JPDA Debugger) to UI module (JPDA Debugger UI). My assumption is that it's handy to have that in the API even for others. So that it can be retrieved programmatically.
To clarify: The tooltip is composed just from NodeModel.getShortDescription(). Breakpoint.getValidityMessage() is just an API method that can be used in the implementation of NodeModel.getShortDescription().
OK. So an enahnced comment for getValidityMessage() would read: Intended for use by ui implementation code, NodeModel.getShortDescription(), for example.
Fine, I'll add that to the Javadoc.
Thanks for the review, I'll integrate this change today evening CET.
The API is committed to trunk: /shared/data/ccvs/repository/debuggercore/api/apichanges.xml,v <-- apichanges.xml new revision: 1.8; previous revision: 1.7 /shared/data/ccvs/repository/debuggercore/api/manifest.mf,v <-- manifest.mf new revision: 1.15; previous revision: 1.14 /shared/data/ccvs/repository/debuggercore/api/nbproject/project.properties,v <-- project.properties new revision: 1.8; previous revision: 1.7 /shared/data/ccvs/repository/debuggercore/api/src/org/netbeans/api/debugger/Breakpoint.java,v <-- Breakpoint.java new revision: 1.7; previous revision: 1.6 /shared/data/ccvs/repository/debuggercore/test/unit/src/org/netbeans/api/debugger/BreakpointsTest.java,v <-- BreakpointsTest.java new revision: 1.9; previous revision: 1.8
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.