RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2]

[Weijun Wang]

On Thu, 25 Aug 2022 23:54:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 931:
>> 
>>> 929:                     // check individual component for match and bail if no match
>>> 930:                     if (prop.indexOf(st.nextToken()) == -1) {
>>> 931:                         return false;
>> 
>> So if `value` has several sub-values, all of them must appear in the `prop` value. Do we need to make this clear in the spec?
>> 
>> Also, you use `indexOf` instead of an exact match to a sub-value in `prop`. Is this always correct? I am wondering if a value can be substring of a different value. I see you support simple class name in the test. Is it worth we doing this? I would rather be strict at the beginning.
>
> Yes, I'd expect if multiple sub-values are specified, it means all of them should appear in `prop` in order to be matched. It does raise an interesting question as to how to do the filtering based on an "OR" relationship. Perhaps an union of 2 separate filter result? I'd suspect that "AND" relationship would be more useful. One alternative is to disallow multiple sub-values, and treat the value as one sub-value. Thoughts?
> 
> As for strict vs loose, I am on the fence, thought that it'd be nice to not having to enter the entire value. Could switch direction to be strict for now and loosen it up if requested.

The spec says the result of `getProviders(map)` must satisfy all criteria, so we already have AND. That sounds like it's better to treat multiple values in a single criterion to be OR.

In fact, I don't know who would want to check for OR. For example, a user might be OK with either GCM or CCM, but it still makes no sense to check for "GCM or CCM". After all, at the end they need to decide whether to call `getInstance("GCM")` or `getInstance("CCM")`. They'd better call `getProviders()` twice to find out which exact one is supported.

Maybe we can only support one value at the moment.

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

PR: https://git.openjdk.org/jdk/pull/10008