Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

David Lloyd david.lloyd at redhat.com
Thu May 10 20:39:12 UTC 2018


Would it be allowed to enable the serial lint without using the
@Serial annotation?

On Thu, May 10, 2018 at 10:55 AM, joe darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
> Please review the webrev (code below) to address
>
>     JDK-8202385: Annotation to mark serial-related fields and methods
>     http://cr.openjdk.java.net/~darcy/8202385.0/
>
> The proposed java.io.Serial annotation type is intended to be used along
> with an augmented implementation of javac's "serial" lint check; that work
> will be done separately as part of JDK-8202056: "Expand serial warning to
> check for bad overloads of serial-related methods".
>
> Currently, javac's serial lint check looks for serialVersionUID fields to be
> declared in Serializable classes. However, there are various other
> structural properties of the declaration of serialization-related fields and
> methods that could be checked at compile-time. The proposed java.io.Serial
> annotation type (name subject to change [*]) explicitly marks fields and
> methods that are intended to be called as part of the Serialization
> machinery. This marking allows using the wrong name for a method or field to
> be easily caught; the serialization mechanism will generally silently ignore
> mis-declared serialization-related fields and methods.
>
> Since the annotation is intended for compile-time checking, the annotation
> type has has source retention, like the Override annotation type.
>
> Cheers,
>
> -Joe
>
> [*] Unleash the bikes from the bikeshed! On the name and package of the
> annotation type, since the other serialization types are in the java.io
> package and the checks are not proposed to be part of the language, this
> annotation type more appropriately lives in java.io package rather than
> java.lang. The name "Serial" is consistent with the "@serial" javadoc tag.
> Other possible names include "Serialize" and "SerialRelated". Another
> possibility would be to have the annotation type be a nested type in
> java.io.Serializable.
>
> -=-=-=-=-=-=-
>
> // GPLv2 elided.
>
> package java.io;
>
> import java.lang.annotation.*;
>
> /**
>  * Indicates that a field or method is related to the {@linkplain
>  * Serializable serialization mechanism}. This annotation type is
>  * intended to allow compile-time checking of serialization-related
>  * declarations, analogous to the checking enabled by the {@link
>  * java.lang.Override} annotation type to validate method overriding.
>  *
>  * <p>Specifically, annotations of this type are intended to be
>  * applied to serialization-related methods and fields in classes
>  * declared to be {@code Serializable}. The five serialization-related
>  * methods are:
>  *
>  * <ul>
>  * <li>{@code private void writeObject(java.io.ObjectOutputStream stream)
> throws IOException}
>  * <li>{@code private void readObject(java.io.ObjectInputStream stream)
> throws IOException, ClassNotFoundException}
>  * <li>{@code private void readObjectNoData() throws ObjectStreamException}
>  * <li><i>ANY-ACCESS-MODIFIER</i> {@code Object writeReplace() throws
> ObjectStreamException}
>  * <li><i>ANY-ACCESS-MODIFIER</i> {@code Object readResolve() throws
> ObjectStreamException}
>  * </ul>
>  *
>  * The two serialization-related fields are:
>  *
>  * <ul>
>  * <li>{@code private static final ObjectStreamField[]
> serialPersistentFields}
>  * <li>{@code private static final long serialVersionUID}
>  * </ul>
>  *
>  * A compiler can validate that a method or field marked with a
>  * <code>@Serial</code> annotation is one of the defined
> serialization-related
>  * methods declared in a meaningful context.
>  *
>  * <p>It is a semantic error to apply this annotation to other fields or
> methods, including:
>  * <ul>
>  * <li>fields or methods in a class that is not {@code Serializable}
>  *
>  * <li>fields or methods of the proper structural declaration, but in
>  * a type where they are ineffectual. For example, {@code enum} types
>  * are defined to have a {@code serialVersionUID} of {@code 0L} so a
>  * {@code serialVersionUID} field declared in an {@code enum} type is
>  * ignored. The five serialization-related methods identified above
>  * are likewise ignored for an {@code enum} type.
>  *
>  * </ul>
>  */
> @Target({ElementType.METHOD, ElementType.FIELD})
> @Retention(RetentionPolicy.SOURCE)
> public @interface Serial {
> }
>



-- 
- DML


More information about the core-libs-dev mailing list