On Fri, 21 May 2021 17:21:15 GMT, Roger Riggs <[email protected]> wrote:
>> src/java.base/share/classes/java/io/ObjectInputFilter.java line 107:
>>
>>> 105: * Note that the filter may be used directly or combined with
>>> other filters by the
>>> 106: * {@linkplain Config#setSerialFilterFactory(BinaryOperator)
>>> JVM-wide filter factory}.
>>> 107: * </ul>
>>
>> This list is a little confusing to me, but could be that I don't fully grok
>> it yet. getSerialFilterFactory returns THE JVM-wide factory, whether that be
>> the built-in factory implementation or not is somewhat irrelevant. No need
>> to treat them differently - one either sets a factory (in which case that is
>> the JVM-wide factory), or one does not set the factory (in which case the
>> built-in factory is the JVM-wide factory).
>
> In previous versions, calling OIS.setObjectInputFilter determined exactly the
> filter used for the stream.
> With the filter factory enhancement, the current filter factory determines
> how the argument to OIS.setObjectInputFilter is used. There are plenty of
> cases where the filter factory will combine it with other filters and the
> composite will becomes the filter for the stream.
Here is the source of my confusion. The bulleted list is enumerating how a
stream-specific filter is determined, but I see an extra step in that which
should be unnecessary. It is currently:
1. Check JVM-wide filter factory
2. If no JVM-wide, check built-in factory
3. setSerialFilterFactory
, but 1 and 2 are not separate and distinct cases - there is always a JVM-wide
deserialization filter factory. The JVM-wide deserialization filter factory is
either i) set through a property, or ii) set explicitly by an API call, or iii)
the built-in implementation.
If the initialisation of the JVM-wide deserialization filter factory is
separated out from how the stream-specific factory is determined, then I
believe that it will be easier to follow.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3996
