Go thru review, make sure the change is
documented, explain why it is needed and prove it
is covered by tests.
> SPI signature test results
> Note: This file lists ALL SPI changes made in
org.netbeans.spi since the build 200411181900.
> APIChangeTest Report
> Base version: 1.4.2_04
> Tested version: 1.4.2_04
> Missing Methods
method public final boolean
> Added Methods
method public boolean
> STATUS:Failed.2 errors
Is this really 4.0 issue?
THIS ISSUE IS P1 - Could anyone respond if this is really 4.0 issue?
If not, please adjust version. Thanks.
Sorry I was OOO.
I need to remove final modif. from
This final modif. is too restricitve in some situations. I was not
able to write some tests without this modification.
Change is already done in cvs, I have changed module version number
and updated apichanges doc. Writing test for this purpose is mad.
I just asked jjancura to write a test for the missing modifier. He did
not want. So, I at least asked him why he needs to remove the final
keyword? He did not know!
I really do not know what to say. Maybe just rollback the change.
If you do not want to rollback, then realize the reason why you
thought it should not be final and simulate that reason in a test.
There has to be externally visible reason for that change!
I do not understand why we should have some special tests for method
modifiers. Does it mean that I should create some special tests for
all my methods? Should I check all modifiers (public, static...)?
I thought that we have some API signature test already established for
You do not need signature tests, we have them. They reported your
change. On level of sigtests the proper fix is to return the final
keyword there. That is the only fix if you do not want to change
semantic of your API.
If you insist on the semantic change, then write test for the
behaviour that is possible now and was not before. And I am not
talking about ability to subclass, but test of the effect of such
subclassing in other parts of the system.
Test is done, not other complaints, so I am closing this issue.
DummyTest is the right name for such dummy test.
I hoped in having a test that would check the change in behaviour of
the debuggercore when ActionsProviderSupport with overriden isEnabled
was provided. But that is likely to much to ask for.