JDK 9 RFR of JDK-6226715: (ann) java.lang.annotation.AnnotationTypeMismatchException could not be serialized
Roger Riggs
Roger.Riggs at Oracle.com
Thu Jun 30 17:25:26 UTC 2016
Joe,
Caveats and all, that seems like a good solution.
+1
Roger
On 6/30/2016 1:18 PM, joe darcy wrote:
> Hello,
>
> Please review the changes to address
>
> JDK-6226715: (ann)
> java.lang.annotation.AnnotationTypeMismatchException could not be
> serialized
> http://cr.openjdk.java.net/~darcy/6226715.0/
>
> Patch below.
>
> The analysis of why is patch is valid requires a bit of explanation.
>
> Like all other exceptions, AnnotationTypeMismatchException is
> serializable. However, its state contains a non-serializable element
> field of type Method. Therefore, previously an
> AnnotationTypeMismatchException with a non-null element field threw an
> exception when serialized. Therefore, the only persisted
> AnnotationTypeMismatchException objects have null element fields in
> the serial output.
>
> The patch changes element to be a transient field, removing it from
> the serial output, *without* changing the serialVersionUID. This would
> not usually be a valid transformation, but limits on what can be
> serialized make it acceptable in this case.
>
> If an old serialized form of an AnnotationTypeMismatchException object
> with a null value for element is deserialized after the patch, the now
> extraneous element information is ignored, yielding a semantically
> correct object (with a null value for element).
>
> If a new serialized form is deserialized against the previous version
> of AnnotationTypeMismatchException, the information for the element
> field is missing, but it gets defaulted to be null, again giving the
> correct semantics.
>
> I've verified this cross-version behavior.
>
> While subtle, I think this change is preferable to introducing
> readObject/writeObject methods to do something like explicit write out
> a null value for the element field in the serial form even if element
> is non-null, etc.
>
> The specification updates make the possibility of nulls explicit.
>
> Thanks,
>
> -Joe
>
>
> ---
> old/src/java.base/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
> 2016-06-30 09:53:08.335033457 -0700
> +++
> new/src/java.base/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
> 2016-06-30 09:53:08.223033453 -0700
> @@ -44,7 +44,7 @@
> /**
> * The {@code Method} object for the annotation element.
> */
> - private final Method element;
> + private final transient Method element;
>
> /**
> * The (erroneous) type of data found in the annotation. This string
> @@ -57,10 +57,12 @@
> * Constructs an AnnotationTypeMismatchException for the specified
> * annotation type element and found data type.
> *
> - * @param element the {@code Method} object for the annotation
> element
> + * @param element the {@code Method} object for the annotation
> + * element, may be {@code null}
> * @param foundType the (erroneous) type of data found in the
> annotation.
> * This string may, but is not required to, contain the value
> - * as well. The exact format of the string is unspecified.
> + * as well. The exact format of the string is unspecified,
> + * may be {@code null}.
> */
> public AnnotationTypeMismatchException(Method element, String
> foundType) {
> super("Incorrectly typed data found for annotation element "
> + element
> @@ -71,8 +73,11 @@
>
> /**
> * Returns the {@code Method} object for the incorrectly typed
> element.
> + * The value may be unavailable if this exception has been
> + * serialized and then read back in.
> *
> - * @return the {@code Method} object for the incorrectly typed
> element
> + * @return the {@code Method} object for the incorrectly typed
> + * element, or {@code null} if unavailable
> */
> public Method element() {
> return this.element;
> @@ -81,7 +86,8 @@
> /**
> * Returns the type of data found in the incorrectly typed element.
> * The returned string may, but is not required to, contain the
> value
> - * as well. The exact format of the string is unspecified.
> + * as well. The exact format of the string is unspecified and
> the string
> + * may be {@code null}.
> *
> * @return the type of data found in the incorrectly typed element
> */
>
More information about the core-libs-dev
mailing list