RFR 9: 8155760 Implement Serialization Filtering

Roger Riggs Roger.Riggs at Oracle.com
Mon Sep 12 20:25:33 UTC 2016


Hi Daniel,

Thanks for the review and suggestions:

Updated in place:
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


On 9/12/2016 1:15 PM, Daniel Fuchs wrote:
> Hi Roger,
>
> ObjectInputStream.java: some cosmetic comments:
>
> 317      * {@link ObjectInputFilter.Config#getSerialFilter() the 
> process-wide filter}.
> 352      * {@link ObjectInputFilter.Config#getSerialFilter() the 
> process-wide filter}.
>
>  => should be @linkplain
ok
>
> 1185      * The filter, when not {@code null}, is invoked during 
> {@linkplain #readObject()}
> 1186      * and {@linkplain #readUnshared readUnshared} for each object
>        (+ also at lines 1207,1208,1211,1212,
> Should that be @link? I saw that in other places, readObject and
> readUnshared were not wrapped in {@code } - so for consistency it
> might make sense to use @linkplain. However the usual idiom would
> be to use {@link }.

ok, with explicit method references and class references it should be @link.

>
> 2046                 // Filter the replacement object
> 2047                 if (rep != null) {
> 2048                     if (rep.getClass().isArray()) {
> 2049                         filterCheck(rep.getClass(), 
> Array.getLength(rep));
> 2050                     } else {
> 2051                         filterCheck(rep.getClass(), -1);
> 2052                     }
> 2053                 }
>
> In this case should the filter be also invoked with the
> class of each element in the substituted array?
> Or is it OK that only the array type is checked (could be
> "[Ljava.lang.Object;" containing elements of classes
> X, Y, Z, but the filter will only see the array type).
The filter sees the type of the object returned from resolveObject 
whether it
is an array or another object type.  In the case of arrays, it is 
usually the array
length that is most interesting to the filter.

Thanks, Roger




More information about the core-libs-dev mailing list