You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geode.apache.org by Alberto Gomez <al...@est.tech> on 2021/11/23 16:44:17 UTC

API check error when adding a new method to a public interface

Hi,

After the introduction of GEODE-9702 (https://issues.apache.org/jira/browse/GEODE-9702), adding a new method to a public interface will make the api-check-test-openjdk11 fail even if a default implementation is provided.

My question is if the goal of this change is to forbid this type of changes in minor versions or if there is a process to follow in order for changes of this type to be added.

I wanted to propose (in an RFC) the addition of a new parameter to the create gateway sender command that would require adding a new method to the GatewaySender interface as well as to other public interfaces and I was wondering if this will be possible at all, and if so, how should I proceed with it.

Thanks,

Alberto

Re: API check error when adding a new method to a public interface

Posted by Alberto Gomez <al...@est.tech>.

Thanks, Anil.

I will do as you suggest.

Alberto
________________________________
From: Anilkumar Gingade <ag...@vmware.com>
Sent: Tuesday, November 23, 2021 7:33 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: API check error when adding a new method to a public interface

Alberto,

I don’t think the intention is to avoid, discourage adding a new method...As you have seen any changes to the API or adding a new API has implications on other parts of the product, it is good to validate/verify and address the dependency across the product and get everything working in accordance (without breaking any compatibility). If you have any requirement please propose through RFC and get an approval.

-Anil.

On 11/23/21, 8:44 AM, "Alberto Gomez" <al...@est.tech> wrote:

    Hi,

    After the introduction of GEODE-9702 (https://issues.apache.org/jira/browse/GEODE-9702), adding a new method to a public interface will make the api-check-test-openjdk11 fail even if a default implementation is provided.

    My question is if the goal of this change is to forbid this type of changes in minor versions or if there is a process to follow in order for changes of this type to be added.

    I wanted to propose (in an RFC) the addition of a new parameter to the create gateway sender command that would require adding a new method to the GatewaySender interface as well as to other public interfaces and I was wondering if this will be possible at all, and if so, how should I proceed with it.

    Thanks,

    Alberto

Re: API check error when adding a new method to a public interface

Posted by Dan Smith <da...@vmware.com>.

First off, it's not reasonable to say that we will not add any new methods to the public API unless we release a new major version. We will continue to add methods to the public API, which is something we've been doing in pretty much every minor version.

Our practice has been to make sure that we provide default implementations of methods added to interfaces that are used for callbacks - for example CacheListener or SecurityManager. These are interfaces that a user implements and geode calls into, so if a user upgraded to a new version their code would be broken without a default method.

We don't do that for interfaces that are not callbacks. For example Cache, Region, or GatewaySender. Users don't inject their own implementations of these interfaces into Geode. I guess we could implement default methods when adding to these classes, but I don't think it really makes sense. You could argue these interfaces should have been final classes, but that would make it harder for folks to mock them in tests.

For this specific case, though, I'm not sure if we need a method on GatewaySender? Alberto, if you want to add a method that is only called by internal code like the create gateway sender command, I think it would be better to add that method to the InternalGatewaySender interface.

-Dan
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Tuesday, November 23, 2021 10:42 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: API check error when adding a new method to a public interface

Adding a new method to a public interface breaks anyone else implementing that interface, for example Spring.

Adding a new method with a default implementation (except in the case where it is purely a composure of existing methods) isn't great either, you would probably have to throw Unsupported exception in the default implementation, which just pushes the mismatch from compile-time to runtime.  Default methods can also still be problematic if existing implementations of the interface happened to already have a method with the same name.

One option for adding new public methods would be to make a proposal for a new major version Geode 2.0.

Another option to consider is creating a new interface (rather than adding to existing interface).  Then change existing impl classes to implement both.

 -Owen

On 11/23/21, 10:33 AM, "Anilkumar Gingade" <ag...@vmware.com> wrote:

    Alberto,

    I don’t think the intention is to avoid, discourage adding a new method...As you have seen any changes to the API or adding a new API has implications on other parts of the product, it is good to validate/verify and address the dependency across the product and get everything working in accordance (without breaking any compatibility). If you have any requirement please propose through RFC and get an approval.

    -Anil.

    On 11/23/21, 8:44 AM, "Alberto Gomez" <al...@est.tech> wrote:

        Hi,

        After the introduction of GEODE-9702 (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9702&amp;data=04%7C01%7Cdasmith%40vmware.com%7C9c70bfb452644c3a670908d9aeb1183f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637732897909772680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WkedxqEIQP3jB6rg9sTS%2FYfwsD%2BlQolQ8zxi6h50PRA%3D&amp;reserved=0), adding a new method to a public interface will make the api-check-test-openjdk11 fail even if a default implementation is provided.

        My question is if the goal of this change is to forbid this type of changes in minor versions or if there is a process to follow in order for changes of this type to be added.

        I wanted to propose (in an RFC) the addition of a new parameter to the create gateway sender command that would require adding a new method to the GatewaySender interface as well as to other public interfaces and I was wondering if this will be possible at all, and if so, how should I proceed with it.

        Thanks,

        Alberto

Re: API check error when adding a new method to a public interface

Posted by Owen Nichols <on...@vmware.com>.

Adding a new method to a public interface breaks anyone else implementing that interface, for example Spring.

Adding a new method with a default implementation (except in the case where it is purely a composure of existing methods) isn't great either, you would probably have to throw Unsupported exception in the default implementation, which just pushes the mismatch from compile-time to runtime.  Default methods can also still be problematic if existing implementations of the interface happened to already have a method with the same name.

One option for adding new public methods would be to make a proposal for a new major version Geode 2.0.

Another option to consider is creating a new interface (rather than adding to existing interface).  Then change existing impl classes to implement both.

 -Owen

On 11/23/21, 10:33 AM, "Anilkumar Gingade" <ag...@vmware.com> wrote:

    Alberto,

    I don’t think the intention is to avoid, discourage adding a new method...As you have seen any changes to the API or adding a new API has implications on other parts of the product, it is good to validate/verify and address the dependency across the product and get everything working in accordance (without breaking any compatibility). If you have any requirement please propose through RFC and get an approval.

    -Anil. 

    On 11/23/21, 8:44 AM, "Alberto Gomez" <al...@est.tech> wrote:

        Hi,

        After the introduction of GEODE-9702 (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9702&amp;data=04%7C01%7Conichols%40vmware.com%7C702629f1dee24c5f348a08d9aeafce3c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637732892374729426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eIIHIcdxkuNpUfHLVQEDW61XA5YaH7%2FZjTo8oURCkc0%3D&amp;reserved=0), adding a new method to a public interface will make the api-check-test-openjdk11 fail even if a default implementation is provided.

        My question is if the goal of this change is to forbid this type of changes in minor versions or if there is a process to follow in order for changes of this type to be added.

        I wanted to propose (in an RFC) the addition of a new parameter to the create gateway sender command that would require adding a new method to the GatewaySender interface as well as to other public interfaces and I was wondering if this will be possible at all, and if so, how should I proceed with it.

        Thanks,

        Alberto

Re: API check error when adding a new method to a public interface

Posted by Anilkumar Gingade <ag...@vmware.com>.

Alberto,

I don’t think the intention is to avoid, discourage adding a new method...As you have seen any changes to the API or adding a new API has implications on other parts of the product, it is good to validate/verify and address the dependency across the product and get everything working in accordance (without breaking any compatibility). If you have any requirement please propose through RFC and get an approval.

-Anil. 

On 11/23/21, 8:44 AM, "Alberto Gomez" <al...@est.tech> wrote:

    Hi,

    After the introduction of GEODE-9702 (https://issues.apache.org/jira/browse/GEODE-9702), adding a new method to a public interface will make the api-check-test-openjdk11 fail even if a default implementation is provided.

    My question is if the goal of this change is to forbid this type of changes in minor versions or if there is a process to follow in order for changes of this type to be added.

    I wanted to propose (in an RFC) the addition of a new parameter to the create gateway sender command that would require adding a new method to the GatewaySender interface as well as to other public interfaces and I was wondering if this will be possible at all, and if so, how should I proceed with it.

    Thanks,

    Alberto