Community
Participate
Working Groups
The @java.io.Serial annotation is used to denote a field is part of the serialization mechanism (See javadoc: https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/io/Serial.html) The Eclipse Java Compiler ignores this annotation and doesn't produce an error when it is used for methods or fields that are not part of the serialization mechanism. Specially, this annotation is there to make sure you have named your method/field correctly and the serialization mechanism will use it. Therefore, the following code should at least produce a warning: class Container implements Serializable { @Serial private Object readresolve() { return this; } } (The error is the wrong method name, it should be readResolve) javac doesn't complain (yet), and generates the class file. At least there should be a way to specify the severity of this error. On a related note, the template for the generated serialVersionUID should also apply the annotation to the field.
Thanks. The javadoc of Serial also mentions: " Note that serialization mechanism accesses its designated fields and methods reflectively and those fields and methods may appear otherwise unused in a Serializable class." We need to make sure, that in an appropriate context these methods & fields are not flagged as unused. Also note, the special cases like for enums & Externalizable. (In reply to Johannes Kuhn from comment #0) > [...] > javac doesn't complain (yet), and generates the class file. do you per chance have a bug number were we can check when / if javac implements this?
I did a short search on the JDK bug database, with no results about support (in the sense of generating warnings) to the JDK. The annotation was added with JDK-8202385 [1]. There is one bug related to the javac compiler: JDK-8231443 [2]. (Doesn't look like an implementation, through.) I expect an implementation (emitting a warning) to be related of the first bug. Anyway, I think it could use the Error/Warnings - Annotation preferences, similar to @NonNull. Also an option to warn if the annotation is missing. For the unused case, I found this on the eclipse bug tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=31495 Looks like they have been special cased. [1]: https://bugs.openjdk.java.net/browse/JDK-8202385 [2]: https://bugs.openjdk.java.net/browse/JDK-8231443
(In reply to Johannes Kuhn from comment #2) > I did a short search on the JDK bug database, with no results about support > (in the sense of generating warnings) to the JDK. > > The annotation was added with JDK-8202385 [1]. > There is one bug related to the javac compiler: JDK-8231443 [2]. > (Doesn't look like an implementation, through.) I'm not an expert regarding annotation processing, but I don't see any need for action in JDT regarding [2]. > I expect an implementation (emitting a warning) to be related of the first > bug. Bug [1] has a link to another related bug, proposing more lint warnings, although it's not what we are looking for: https://bugs.openjdk.java.net/browse/JDK-8202056 > Anyway, I think it could use the Error/Warnings - Annotation preferences, > similar to @NonNull. I'm not convinced we need a new preference. Perhaps subsume it with the existing warning regarding serialVersionUID. > Also an option to warn if the annotation is missing. > > For the unused case, I found this on the eclipse bug tracker: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=31495 > Looks like they have been special cased. Right, so most of it is already implemented. I only see method readObjectNoData() still missing. > [1]: https://bugs.openjdk.java.net/browse/JDK-8202385 > [2]: https://bugs.openjdk.java.net/browse/JDK-8231443
Setting a target just so we can check when javac will implement this.
Bulk move out of 4.16
bulk move out of 4.19 - retarget once an owner is assigned
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
