On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >> https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are >> extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and >> `ObjectInputStream`: >> >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Simplify factory interface to BinaryOperator<ObjectInputFilter> and cleanup > the example src/java.base/share/classes/java/io/ObjectInputFilter.java line 365: > 363: * A utility class to set and get the JVM-wide deserialization > filter factory, > 364: * the static JVM-wide filter, or to create a filter from a pattern > string. > 365: * If a JVM-wide filter factory or static JVM-wide filter is set, it > will determine the filter This concerns me, "A JVM-wide filter factory". I was going to suggest that it should be "The ..", but then realised that there can only ever be one present at a time, but in the lifetime of a JVM there can be two (since getSerialFilterFactory if invoked before setSerialFilterFactory will subsequently return a different JVM-wide factory). Is this intentional? It would great if this could be "The ..", so that setXXX can only be invoked successfully if getXXX has not been. This may seen somewhat insignificant, but the fact that the JVM-wide factory can change make the model harder understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996
