On Tue, 25 May 2021 09:14:38 GMT, Chris Hegarty <che...@openjdk.org> wrote:
>> The spec/code is forthcoming. >> ii) is sufficient to prevent ambiguity in which filter is used throughout >> the Java runtime; >> though it requires a bit of package-private plumbing. >> >> i) is too limiting. It should be possible for an application to check >> whether a filter factory has been provided on the command line (by calling >> getSerialFilterFactory) and if not setting the factory itself. It may also >> want to install its own filter factory that delegates to the builtin factory >> without needed to re-implement the builtin behavior. > >> i) is too limiting. It should be possible for an application to check >> whether a filter factory has been provided on the command line (by calling >> getSerialFilterFactory) and if not setting the factory itself. It may also >> want to install its own filter factory that delegates to the builtin factory >> without needed to re-implement the builtin behavior. > > How is this supposed to work in practice? getSerialFilterFactory always > returns a non-null factory, so how does one know whether or not the returned > factory is the built-in factory, a factory set by the command line (or > security property) ? (without resorting to implementation assumptions) If the app does not recognize the filter factory (by its class or module) then try to replace it. If it succeeds, the app is good to go. If it throws an exception then your app is not likely to run and should fail. Newer APIs generally make it possible to detect the state of things without throwing but in this case it would add extra API surface. Some alternatives, check the module of the filter returned, if it is java.base then replacing it is ok to replace. (yes an implementation assumption). An alternative would be to add a static method to return the builtin filter; creating it if has not already been created. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996
