On Wed, 12 Apr 2023 21:48:27 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> Not exactly sure what you want. Security providers need to implement it and >> the `KEM` class uses it. Unlike other `AbcSpi` classes, it will not be >> created with a `getInstance` method. > > If I get it right, SPI means "service provider interface", which is normally > for public service access by searching the registers. In the provider > implementation, a SPI implementation is normally registered so that it can be > accessed. I did not find the registration in the provider implementation. I > know it is right because it is not expected to be registered as it is not > expected to be accessed directly. > >> Security providers need to implement it and the KEM class uses it. > I know, but it is not necessarily designed as an SPI (it could be a normal > interface that a provider need to implement and KEM class uses). You can > code like this, but I'm not sure if it is the common way. 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. :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1164707588
