Sorry for being late to this party. I like the approach, but I have some concerns about the evolvability of this API. The filter already receives a handful of parameters; it seems quite unlikely that a use case will not emerge where the filter needs more information in the future (say, the caller context, the caller class loader, etc.) One strategy for evolution is, rather than pass a handful of parameters, pass an aggregate, where the aggregate has getters for the parameters. Then more getters can be added in the future. There are other strategies too - but I am concerned about being in a migration situation only a few years down the road, where there is information that the filter needs.
> On Sep 8, 2016, at 12:09 PM, Roger Riggs <roger.ri...@oracle.com> wrote: > > Please review updates to the Serialization filtering API and implementation: > - The ObjectInputFilter pattern based filters support matching on module > names as well as package and class names. > - Rename of system property and java.security property for configurable > filters. (jdk.serialFilter) > - ObjectInputFilter clarifications about the values passed to the filter > - Javadoc editorial improvements > - Clarification of SerializablePermission description of targets > > - More tests > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ > > SpecDiff: > http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html > > Javadoc (subset) > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html > > http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html > > Thanks, Roger > > >
