Hi,
I am a bit confused on how to proceed now. I should mark the 3 interfaces with @noreference, @noextend and @noimplement. If I do this the API tooling tells me that I need to update the major version of the core.services bundle to 3.0.0. Is that correct?
Then I should deprecate the using API and add an updated API to be used instead. But the interfaces can be replaced with the java.util.function interfaces directly. The MessageXxx interfaces were intended to be used with Java 8 lambdas. So if I introduce new methods that take the Java functional interfaces and deprecate the old ones, the usage of the methods with lambdas complain about deprecation because the old methods are still used by the compiler. I am not 100% sure, but I suppose it is because of the target type inference algorithm that first uses matching custom implemented interfaces before falling back to default functional interfaces. But to be honest, I have not found information about that detail in target typing.
Anyhow, the issues should be located in BaseMessageRegistry. The interfaces were introduced for lambda usage. Therefore implementing the MessageXxx interfaces should not have happened (but you never know). Also the methods in BaseMessageRegistry should not have been overridden. But as they are not marked as final, it could have happened.
So should I only mark the interfaces and increase the plugin version? I also tried for a start to extend the java.function interfaces so internally the BaseMessageRegistry operates on them. But that does not solve the API usage of BaseMessageRegistry. Or is there some mechanism that I missed that would help in making such a change backwards compatible?
Greez,
Dirk
