> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote:
> If someone really cares about the result of getProvider(), they should be
> careful no other thread calls encapsulation or decapsulation.
If no-one care about the result of getProvider(), is it possible to remove this
method from the desi
> On Jan 26, 2023, at 12:48 AM, Xuelei Fan wrote:
>
>
>> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote:
>
>
>> If someone really cares about the result of getProvider(), they should be
>> careful no other thread calls encapsulation or decapsulation.
>
> If no-one care about the result o
> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote:
> If someone really cares about the result of getProvider(), they should be
> careful no other thread calls encapsulation or decapsulation.
If no-one care about the result of getProvider(), is it possible to remove this
method from the desi
> On Jan 25, 2023, at 11:13 PM, Xuelei Fan wrote:
>
> For delayed provider selection, what’s the selection behavior for
> KEM.getProvider()and KEM.getInstance(String alg, Provider p)?
If getInstance(alg, p) is called, there won't be delayed provider selection.
> Could the provider be determi
For delayed provider selection, what’s the selection behavior for
KEM.getProvider()and KEM.getInstance(String alg, Provider p)? Could the
provider be determined and reliable if the methods are used in an application?
Is the behavior the same if the calling sequences in an application are not
e
Hi Xuelei,
That's a bold suggestion. However, we'd like to the tradition of JCA/JCE at the
moment.
Thanks,
Max
> On Jan 25, 2023, at 3:03 PM, Xuelei Fan wrote:
>
> For new set of service APIs, it may be worthy of considering to simplify the
> design and avoid duplicated SPIs by using java.
For new set of service APIs, it may be worthy of considering to simplify the
design and avoid duplicated SPIs by using java.util.ServiceLoade.
Xuelei
> On Jan 25, 2023, at 11:24 AM, Wei-Jun Wang wrote:
>
> Hi All,
>
> We are working on providing a new API for KEM (Key Encapsulation Mechanism)
