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
> Javadoc (subset)
> Thanks, Roger