On Sun, 15 Dec 2024 09:15:10 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, Java SE service type class is not a final class normally. It means > applications can override it, and thus can break the filter boundary. Github > search implies a few cases that override Signature, [here is > one](https://github.com/cping/RipplePower/blob/4bdfd7ddca69e2cfb2c33852379844880cfe2a2a/eclipse/jcoinlibs/src/net/i2p/crypto/eddsa/EdDSAEngine.java) > with public constructor and get used. Developers can make more surprises > even Java API specification are strictly followed. I think it was discussed early on that the proposal cannot solve all situations. The most obvious case is algorithms that don’t use the Provider API at all. The admin has to be aware of the providers and apps they are using with the JDK. Given that FIPS 140 is a consumer of this feature, additional scrutiny by the admin is anticipated. While I agree having some classes `final` would help, the solution needs to be best effort using the current SPI to support current provider implementations. A pluggable API may be the most flexible, but it requires third parties to implement it and their own syntax. Using an older provider makes this feature useless. It would be nice if the JDK did not have this burden, but I don’t think an alternate has proven to be more effective. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2546698038
