On Wed, 12 Apr 2023 22:59:23 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> So you think the name is misleading? >> >> Well, at the beginning there is only the `Encapsulator` interface inside >> `KEMSpi`, and the `Encapsulator` class in `KEM` implements it with an extra >> `provider()` method. However, I think this connection is unnecessary because >> the provider writers and application writers are completely separated and >> there is no need for one side to learn any knowledge of the other side. So I >> disconnect them but keep using the same names. But then if you want to talk >> about one you have to say which class it is in, and this could be confusing >> and sometimes wrong. Finally I decided to add the `Spi` suffix to them. Yes, >> it's a little different from the other SPI classes since it's not directly >> returned by `getInstance`. However, because of delayed provider selection, I >> believe it's precise to say it's only on the encapsulator and decapsulator >> level that the service itself is provided, and that's also why the >> `provider()` method is on this level. Think of this as the new style of SPI. >> :-) > >> So you think the name is misleading? > > Yes. > >> But then if you want to talk about one you have to say which class it is in, >> and this could be confusing and sometimes wrong. > > I did not get the idea yet to define it in KEPSpi. It looks like that only > one interface in the KEM should be sufficient. The interface implementation > details could be provider based. It is OK to have an provider implementation > implements an interface internally. If the interface is only in `KEM`, then it needs a `provider()` method, but an implementation actually does not know what the provider is. An implementation can be registered in any (or even multiple) providers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164754710
