RFR: 8297878: KEM: Implementation

[Weijun Wang]

On Wed, 12 Apr 2023 22:59:23 GMT, Xue-Lei Andrew Fan <xuelei at 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