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 <onich...@vmware.com>
Sent: Tuesday, November 23, 2021 10:42 AM
To: dev@geode.apache.org <dev@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" <aging...@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" <alberto.go...@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&data=04%7C01%7Cdasmith%40vmware.com%7C9c70bfb452644c3a670908d9aeb1183f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637732897909772680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WkedxqEIQP3jB6rg9sTS%2FYfwsD%2BlQolQ8zxi6h50PRA%3D&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
