RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5]

[Martin Balao]

On Thu, 3 Apr 2025 00:27:50 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Provider.java line 1037:
>> 
>>> 1035:             }
>>> 1036: 
>>> 1037:             if (mi.isLegacy) {
>> 
>> For legacy entry, there is no check on the `legacyApiCall` value, is this due to the call path from `resolveKeyConflict` method? However, should a legacy entry be removed by the `removeService` method? If not, then additional check may be needed?
>
> There is no check because entries added with the Legacy API can be removed (i.e. overwritten) with entries added with the Current API. Current API operations take precedence.
> 
> Looks like someone can invoke `removeService` with a Service instance whose algorithm was added with the Legacy API and the code is not stopping this removal. May be a good idea to stop this. @franferrax , what do you think?

We discussed this further with @franferrax and don't necessarily see the proposed behavior as a problem. To put this into some context first, it's very unlikely that someone builds a Service instance with the same algorithm of a Legacy API entry and invokes `removeService`. Even if that's the case, the service will be removed and the principle of "the Current API takes precedence" applies. This principle is also used when overriding a Legacy API value with `putService` —behavior that comes from before of our change. Our motivation for enforcing no modification of services added with the Current API from the Legacy API was to preserve service immutability, which would not be at stake here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2027792005