On Fri, 13 Dec 2024 05:14:07 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
> It's only the combination of a Provider that overrides getService/getServices > + does not call putService/put + overrides newInstance without calling its > parent + uses a non-Java SE service type that would be unfiltered. FYI. I found [a case](https://www.bouncycastle.org/download/bouncy-castle-java-fips/) that: 1. Override getService/getServices, has its own logic to use put properties. 2. Use extended Provider.Service, but not Provider.Service directly. 3. call put() and get() internally. But because of `#1` and `#2`, the provider filter theory may not work, please verify. 4. overrides newInstance without calling its parent. 5. uses non-Java SE service types This is a popular provider (IIRC 17% marketing share per a report). I think you should have evaluated it and confirmed that the theory works. Otherwise, please make sure the compatibility issues is limited and the theory works for it. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2543514140
