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.
Unless the thread is suspended, it should be possible to interrupt it. In the Threads view, there can be "Interrupt" context action.
Would be a simple fix, if an API change is not necessary. But we need to use the JPDAThread abstraction, which does not have interrupt() method. Therefore we need a fast API review for this.
Created attachment 22222 [details] The proposed API change together with implementation.
The JPDAThread interface is not to be implemented by the clients. Therefore a method addition there should be considered as a compatible change.
Thanks for asking for review before the actual integration has happened. As far as I know the jpda api has official stability and thus we should try as much as we can to maintain it in compatible way[1], that is why I'd like you to consider solution that would evolve the api. Even if we do not know about someone subclassing the JPDAThread, by declaring the api official, we accept the fact that someone can do it and we have to behave like someone really did it[1]. Moreover I can imagine valid use case where subclassing is used for delegation and filtering (better name of a thread). Afaik this is encouraged by viewmodel's filters and thus it is not unlikely someone is trying that. That is why please do not add new method to your interface. Another thing I'd like to encourage is to write a test that the behaviour of INTERRUPT_ACTION is correct. Please check that it is disabled if old implementation of JPDAThread is passed in and enabled only if new implementation that supports interuptions is passed in. Should be pretty simple and gives meaningness to your api change. [1] of course we do not need to, if there is no way around, but in this case there seems to be one.
Yarda, I think that your argument is not valid. Martin would like to add some method to API, which should not be recognized as incompatible change. Our Java debugger is based on JDI interface. JDI API contains many interfaces, and these interfaces are changing (they are adding new nethods there). THis is incompatible change in your rules! I think that we can not use more strict rules for NetBeans APIs, than rules used for JDK! Reconsider it, please.
Removing from API review for now, we need to solve issue #59129 first.
Created attachment 22466 [details] Here is a simple solution that does not look bad, can be repeated in future if needed and is likely to pass API_REVIEW_FAST. Consider it, please.
After issue #59129 is resolved, I'm moving this to review again. The review was already requested in the past, but the change could not be done until issue #59129 is resolved. Thus I expect this to be a seamless process... The change is described in http://www.netbeans.org/nonav/issues/showattachment.cgi/22222/59072.txt
Thanks for the review, I'll commit the change later today...
Fixed in trunk: /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/models/Bundle.properties,v <-- Bundle.properties new revision: 1.27; previous revision: 1.26 /cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/JPDAThread.java,v <-- JPDAThread.java new revision: 1.7; previous revision: 1.6 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/models/JPDAThreadImpl.java,v <-- JPDAThreadImpl.java new revision: 1.13; previous revision: 1.12 /cvs/debuggerjpda/api/apichanges.xml,v <-- apichanges.xml new revision: 1.11; previous revision: 1.10 /cvs/debuggerjpda/api/manifest.mf,v <-- manifest.mf new revision: 1.12; previous revision: 1.11
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.