I have 0 issues with ServiceLoader, but I think the bigger question is “what is a public api”. In #1 I see the first comment is
> The `CustomConstraintsProvider` class will create custom constraints. This implies to mean that this is a new public API that must be maintained, and the current process for these is to reach out to dev@. We don’t have any process to even know what is public API nor do we do anything to make sure we don’t break compatibility with java APIs. In the example you shown with SSTables, the format isn’t public API (at least thats my memory), this was kinda mostly done to enable testing. AKA if someone tries to use this and one of our patch fix versions makes a breaking change, thats on you for using a private API. > For constraints, I think it would be very welcome if people are allowed to > code their own constraints and just put it on CP and it would be picked up > automatically. If they are not stored in TCM and side loaded into each node, what happens when some of the nodes do not have them loaded? This had been a big pain point with the memtable patch (issue is partially fixed, we no longer crash, but we no longer respect user configs either). > On Aug 11, 2025, at 8:31 AM, Štefan Miklošovič <smikloso...@apache.org> wrote: > > I want to ask what people think about ServiceLoader's (Java SPI) in the > context of Cassandra. > > There is already a precedent with > > ServiceLoader<SSTableFormat.Factory> loader = > ServiceLoader.load(SSTableFormat.Factory.class, > DatabaseDescriptor.class.getClassLoader()); > > in DatabaseDescriptor.applySSTableFormats > > I am asking because I would like to do (1, 2) and I find SPI to be the most > suitable for it. Just drop a JAR among Cassandra jars and be done with it. > > This means that there is no change in the configuration of cassandra.yaml and > similar. On the other hand, we kind of lose the visibility of what we are > actually running. What I mean by that is that when it is configured in > cassandra.yaml and done as "ParameterizedClass", it is pretty explicit what > configuration we use for what. On the other hand, by placing a JAR to > Cassandra class path, while it is super simple to do, the only visible way to > tell a user if there is some custom stuff loaded is to log it as Cassandra > starts. > > What do you think about the SPI approach in general? There might also be > other advantages as providing more implementations and ordering them by > priority etc. > > Is SPI's way of registering / loading custom implementations just fine and > can be considered as something developers can choose to do if they think it > fits the use-case enough? > > For constraints, I think it would be very welcome if people are allowed to > code their own constraints and just put it on CP and it would be picked up > automatically. It would speed up the development, they would not need to wait > for us to merge them and release them and they could have proprietary / > in-house constraints just for their use case while they do not need to patch > Cassandra itself. Hence they can still use the official release but they > could extend it as they want. > > Regards > > (1) > https://github.com/apache/cassandra/pull/4297/files#diff-d6e8754d8326be6063d9d59265e882416d74007e47f07f809267b07f9860e26d > (2) https://issues.apache.org/jira/browse/CASSANDRA-20824
