Skip to content
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

8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc #5728

Closed
wants to merge 4 commits into from

Conversation

jddarcy
Copy link
Member

@jddarcy jddarcy commented Sep 28, 2021

Augmentations to javac's Xlint:serial checking are out for review (#5709) and various javac and javadoc implementation libraries would need some changes to pass under the expanded checks.

The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

I'll run a script to update the copyright year before pushing.

Sending this change out for review separately in an effort to de-bulk the review needed for the new checks themselves.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5728/head:pull/5728
$ git checkout pull/5728

Update a local copy of the PR:
$ git checkout pull/5728
$ git pull https://git.openjdk.java.net/jdk pull/5728/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5728

View PR using the GUI difftool:
$ git pr show -t 5728

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5728.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 28, 2021

👋 Welcome back darcy! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label Sep 28, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 28, 2021

@jddarcy The following labels will be automatically applied to this pull request:

  • compiler
  • javadoc

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.

@openjdk openjdk bot added javadoc compiler labels Sep 28, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 28, 2021

Webrevs

Copy link
Member

@pavelrappo pavelrappo left a comment

Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.

@jddarcy
Copy link
Member Author

@jddarcy jddarcy commented Sep 29, 2021

Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.

Same semantics. The first phase of this cleanup used "not statically Serilizable"; however, I thought "not a Serilizable type" is a more precise statement. I can make a pass over the PR and make the wording consistent in the new comments.

@pavelrappo
Copy link
Member

@pavelrappo pavelrappo commented Sep 29, 2021

Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.

Same semantics. The first phase of this cleanup used "not statically Serilizable"; however, I thought "not a Serilizable type" is a more precise statement. I can make a pass over the PR and make the wording consistent in the new comments.

You could update this PR if only to fix the typo; the phrasing is up to you.

@jddarcy
Copy link
Member Author

@jddarcy jddarcy commented Sep 29, 2021

Is there any semantic difference between "not statically Serilizable" and "not a Serilizable type"? Also, there's a typo: Seri-a-lizable.

Same semantics. The first phase of this cleanup used "not statically Serilizable"; however, I thought "not a Serilizable type" is a more precise statement. I can make a pass over the PR and make the wording consistent in the new comments.

You could update this PR if only to fix the typo; the phrasing is up to you.

Wording updated.

Copy link
Member

@pavelrappo pavelrappo left a comment

The javadoc changes look good. Hopefully, those Result errors, whose serial warnings this PR suppresses, will go away in JDK-8267690.

@openjdk
Copy link

@openjdk openjdk bot commented Sep 29, 2021

@jddarcy This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8274405: Suppress warnings on non-serializable non-transient instance fields in javac and javadoc

Reviewed-by: prappo, jjg

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 no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Sep 29, 2021
Copy link
Contributor

@jonathan-gibbons jonathan-gibbons left a comment

There are 3, maybe just 2, groups of files in this review.

sjavac is an internal utility that ought not to be in the src/ tree, so the changes there don't matter.

The various Result classes and the javadoc exceptions are all "internal" exceptions used for internal control flow, and not intended to be seen by API clients. As @pavelrappo notes, we have plans to make the Result classes go away by rewriting the relevant scanners to make them unnecessary. That leaves the javadoc exceptions. The commented annotations have a slight code-smell about them, in the sense of brushing the warning under the carpet, so to speak. It would be better if there was a better way to remove the cause of the warning, rather than just hiding the warning itself. But, that's not easy, and the original sin was making Throwable (and hence all subtypes) implement Serializable in the first place. But, that's the serialization we have and we have to deal with it.

As a final note, I never did like the Runnable in the last exception, and seeing it again may be a good reason to try and get rid of it, like those Result classes mentioned earlier. I also note that DocPath could be made Serializable but DocFile cannot reasonably be made serializable (incompatible API change to Location) and even thinking about it seems like a case of the tail wagging the elephant!

So, with some disappointment, I accept that the changes you propose are the least bad of the possible solutions, at least for now, and so I approve the review.

@jddarcy
Copy link
Member Author

@jddarcy jddarcy commented Sep 29, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Sep 29, 2021

Going to push as commit 97385d4.

@openjdk openjdk bot closed this Sep 29, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Sep 29, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 29, 2021

@jddarcy Pushed as commit 97385d4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@jddarcy
Copy link
Member Author

@jddarcy jddarcy commented Sep 29, 2021

There are 3, maybe just 2, groups of files in this review.

sjavac is an internal utility that ought not to be in the src/ tree, so the changes there don't matter.

The various Result classes and the javadoc exceptions are all "internal" exceptions used for internal control flow, and not intended to be seen by API clients. As @pavelrappo notes, we have plans to make the Result classes go away by rewriting the relevant scanners to make them unnecessary. That leaves the javadoc exceptions. The commented annotations have a slight code-smell about them, in the sense of brushing the warning under the carpet, so to speak. It would be better if there was a better way to remove the cause of the warning, rather than just hiding the warning itself. But, that's not easy, and the original sin was making Throwable (and hence all subtypes) implement Serializable in the first place. But, that's the serialization we have and we have to deal with it.

As a final note, I never did like the Runnable in the last exception, and seeing it again may be a good reason to try and get rid of it, like those Result classes mentioned earlier. I also note that DocPath could be made Serializable but DocFile cannot reasonably be made serializable (incompatible API change to Location) and even thinking about it seems like a case of the tail wagging the elephant!

So, with some disappointment, I accept that the changes you propose are the least bad of the possible solutions, at least for now, and so I approve the review.

If I were to see

@SuppressWarning("serial") // Type of field not Serializable
Foo foo;

in new code I would question the serial-design of the class; that is one of my goals with augmenting the Xlint:serial checks, notice possibly questionable serial coding patterns sooner.

For types where maintaining cross-release serial compatibility is not strictly needed, one approach would be to mark the fields as transient and give the class a different serialVersionUID. If serial compatibility is needed the conceptually transient field, i.e. one that cannot meaningful be serialized, could be nulled-out in a writeObject method and ignored in a readObject method, at the cost of maintaining those additional methods.

Fortunately, the the javax.lang.model API, the issues with exception classes having non-Serializable fields was recognized during the design and we marked all such fields and transient and documented the corresponding getters to possibly return null.

@jddarcy jddarcy deleted the JDK-8274405 branch Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler integrated javadoc
3 participants