New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8259522: Apply java.io.Serial annotations in java.desktop #2020
Conversation
|
@mrserb The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
/** | ||
* Use serialVersionUID from JDK 1.7 for interoperability. | ||
*/ | ||
@Serial | ||
private static final long serialVersionUID = 1L; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. There are several classes which extend this one, all of them use the same 1L value which makes it not "quite" unique.
Changing the values at this time presents more risks than benefits.
src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
Outdated
Show resolved
Hide resolved
src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
Outdated
Show resolved
Hide resolved
@mrserb This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 61 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
…ption.java Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk@users.noreply.github.com>
…on.java Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk@users.noreply.github.com>
Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes?
Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check?
Most Swing classes are marked by the specific "Warning" that "Same-version serialization only" is supported. (I think such a warning is missed in a few classes). So generally the serialVersionUID field is not needed in such classes, but if present this provides a small benefit -> this UID is not generated at runtime. For example, the DefaultMutableTreeNode was updated by the JDK-5017904 fix, which was unrelated to serialization but was targeted for the performance issue.
At some point, we probably can remove it but will need to fix all serialization warnings which were disabled. |
/integrate |
@mrserb Since your change was applied there have been 111 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 978bed6. |
Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
This annotation can be applied to these methods in the module:
Notes:
A similar fix was implemented for java.base module as well:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2020/head:pull/2020
$ git checkout pull/2020