[11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env

[David Alvarez]

Hi Martin,

Indeed, having a service registered twice is possible since the dual map 
was added. I've checked this behavior in the current version (add two 
services with the same algorithm, different class and then use 
Provider.put to add an alias).

Requesting the algorithm will return the one that was registered with 
putService. Requesting the alias will also return the one registered 
with putService.

However, some problems:
- Enumerating all the services via getServices will return both services
- The service registered with putService will have an empty aliases list
- The service registered with put will have the registered alias in the 
aliases list

The fact that you can register two services with the same name is not 
what this patch is fixing, but we might make the behavior a bit more 
consistent if we make it so we look into the serviceMap before we look 
into the legacyMap when we add aliases. At least, that way the service 
that is returned when requesting the alias will have the aliases list 
populated.

I've created an updated webrev with this version:
http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.01/

David

On 2020-09-22 12:11, Martin Balao wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hi David,
> 
> On Tue, Sep 22, 2020 at 3:31 PM David Alvarez <alvdavi at amazon.com> wrote:
>> These are not used for registering aliases. [1] is the path used to
>> register a new service and [2] is used to register an attribute. They
>> both fetch the legacyMap because they can also be used to modify an
>> existing value (either the class for an algorithm or the value of an
>> attribute).
> 
> Thanks for your clarification. I see your point. It should be possible
> to have a service registered twice (same name, different impl classes
> eventually): once with the putService API and once with the legacy
> API. Same for a service attribute. But this is unsupported: we are not
> expecting this information to be sync.
> 
> Ok, looks good to me.
> 
> Thanks,
> Martin.-
>