On Thu, 3 Apr 2025 00:27:50 GMT, Martin Balao <mba...@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
