...
- The interface changes resulting from security fixes can severely impair the contracts of the implementing classes. It is even possible that a security fix introduced in a later version is accompanied by modifications to an unrelated interface that must now be implemented by the client. This can prevent the client from implementing the security fix because the new interface may impose additional implementation burden on it.
- If an insider crafts changes to an interface or someone accidentally makes modifications, most of the client code that implements the interface will break resulting in denial of service. This is particularly pernicious in distributed Java based applications.
- Implementers can provide skeletal implementations that the clients can directly extend, however, such code can adversely affect the behavior of the subclasses. When such default implementations are not provided, the subclasses are forced to provide dummy implementations. This fosters an environment where comments such as 'ignore this code, does nothing', occur incessantly. Such code may never even get tested.
- If there is a security flaw in a public API (consider ThreadGroups, CON01CON17-J. Avoid using ThreadGroup APIs) it will persist throughout the lifetime of the application.
...