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()
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, 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. 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.
 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
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
Thanks for the review, I'll commit the change later today...
Fixed in trunk:
new revision: 1.27; previous revision: 1.26
new revision: 1.7; previous revision: 1.6
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.