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.
Summary: | I need to remove final modif. from ActionsProviderSupport.isEnabled(java.lang.Object) | ||
---|---|---|---|
Product: | debugger | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Code | Assignee: | apireviews <apireviews> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | apireviews |
Priority: | P1 | Keywords: | API_REVIEW_FAST |
Version: | 4.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jaroslav Tulach
2004-12-03 10:23:15 UTC
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 ActionsProviderSupport.isEnabled(java.lang.Object). 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 that purpose. 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. Test: trunk\debuggerjpda\test\unit\src\org\netbeans\api\debugger\jpda\DummyTests.java 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. |