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

fix serialization warnings in generated code when compiling with Java 18 and above #10561

Merged
merged 2 commits into from
Sep 30, 2022

Conversation

xvrl
Copy link
Contributor

@xvrl xvrl commented Sep 14, 2022

Java 18 added additional linter checks as part of
https://bugs.openjdk.java.net/browse/JDK-8274336 and https://bugs.openjdk.java.net/browse/JDK-8274335

These additional checks cause generated protobuf code to raise the following compiler warning: "non-transient instance field of a serializable class declared with a non-serializable type"

This change fixes the code generation to annotate the generated fields with the necessary suppressions to avoid false positives.

All the code generated from src/google/protobuf/*.proto now compiles successfully without serialization warnings in Java 18.

fixes #9673

… version 18 and above

Java 18 added additional linter checks as part of
https://bugs.openjdk.java.net/browse/JDK-8274336 and
https://bugs.openjdk.java.net/browse/JDK-8274335

These additional checks cause generated protobuf code to raise the
following compiler warning: "non-transient instance field of a
serializable class declared with a non-serializable type"

This change fixes the code generation to annotate the generated fields
with the necessary suppressions to avoid false positives.

All the code generated from src/google/protobuf/*.proto now
compiles successfully without serialization warnings in Java 18.

fixes protocolbuffers#9673
@google-cla
Copy link

google-cla bot commented Sep 14, 2022

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@@ -335,6 +335,7 @@ void ImmutableMapFieldGenerator::GenerateMembers(io::Printer* printer) const {
" $value_default_value$);\n"
"}\n");
printer->Print(variables_,
"@SuppressWarnings(\"serial\")\n"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this may not actually be a false-positive, since I could not find any evidence that any MapField types are actually serializable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that our custom serialization format is implemented in such a way that we dump a bunch of details into the serialization that are not actually used in the deserialization (which is really accomplished through proto deserialization). This is probably fine until we can fix the serialization format to drop things that shouldn't be there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good, thanks for checking

@xvrl xvrl changed the title fix serialization warnings in generated code when compiling with Java version 18 and above fix serialization warnings in generated code when compiling with Java 18 and above Sep 14, 2022
@acozzette acozzette requested a review from zhangskz September 14, 2022 21:07
@zhangskz zhangskz requested a review from googleberg September 15, 2022 15:23
@@ -335,6 +335,7 @@ void ImmutableMapFieldGenerator::GenerateMembers(io::Printer* printer) const {
" $value_default_value$);\n"
"}\n");
printer->Print(variables_,
"@SuppressWarnings(\"serial\")\n"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that our custom serialization format is implemented in such a way that we dump a bunch of details into the serialization that are not actually used in the deserialization (which is really accomplished through proto deserialization). This is probably fine until we can fix the serialization format to drop things that shouldn't be there.

@zhangskz zhangskz removed their request for review September 28, 2022 17:12
@xvrl
Copy link
Contributor Author

xvrl commented Sep 30, 2022

@fowles any details on what the aarch64 failure might be?

@fowles
Copy link
Contributor

fowles commented Sep 30, 2022

@fowles any details on what the aarch64 failure might be?

Most likely a flake or bad sync point. Can you rebase onto tip of tree and I will rerun?

@acozzette
Copy link
Member

I kicked off a rerun of the failing test, let's see if maybe that will fix it. I believe the test infrastructure will run tests with the latest main merged in, so there shouldn't be any need to do a rebase.

@fowles fowles merged commit 6757a0b into protocolbuffers:main Sep 30, 2022
@xvrl xvrl deleted the issue-9673 branch September 30, 2022 17:43
@xvrl
Copy link
Contributor Author

xvrl commented Oct 24, 2022

@googleberg I didn't see this change included in the latest release. Is there anything else we need to do? I'm not very familiar with the process.

@xvrl
Copy link
Contributor Author

xvrl commented Jan 17, 2023

@googleberg @acozzette @fowles I was hoping this would make it into one of the recent releases but I may not have followed the right process. Should I be submitting a new PR to cherry-pick this change into the 21.x branch to make sure it makes it into the next release?

@googleberg
Copy link
Member

@xvrl this would naturally end up in the next minor-version release (3.22). We don't typically merge non-critical changes into patch releases. We are hoping to establish a more regular cadence of minor releases this year.

@xvrl
Copy link
Contributor Author

xvrl commented Jan 17, 2023

👍 thanks for clarifying

srowen pushed a commit to apache/spark that referenced this pull request Feb 20, 2023
### What changes were proposed in this pull request?
This pr aims upgrade `protobuf-java` from 3.21.12 to 3.22.0

### Why are the changes needed?
The new version bring some improvements like:

- Use bit-field int values in buildPartial to skip work on unset groups of fields. (protocolbuffers/protobuf@2326aef)
- Fix serialization warnings in generated code when compiling with Java 18 and above (protocolbuffers/protobuf#10561)
- Enable Text format parser to skip unknown short-formed repeated fields. (protocolbuffers/protobuf@6dbd413)
- Add serialVersionUID to ByteString and subclasses (protocolbuffers/protobuf#10718)

and some bug fix like:
- Mark default instance as immutable first to avoid race during static initialization of default instances. (protocolbuffers/protobuf#10770)

- Fix Timestamps fromDate for negative 'exact second' java.sql.Timestamps (protocolbuffers/protobuf#10321)
- Fix Timestamps.fromDate to correctly handle java.sql.Timestamps before unix epoch (protocolbuffers/protobuf#10126)
- Fix bug in nested builder caching logic where cleared sub-field builders would remain dirty after a clear and build in a parent layer. protocolbuffers/protobuf#10624

The release notes as follows:

- https://github.com/protocolbuffers/protobuf/releases/tag/v22.0

### Does this PR introduce _any_ user-facing change?
No

### How was this patch tested?
Pass GitHub Actions

Closes #40084 from LuciferYang/SPARK-42490.

Authored-by: yangjie01 <yangjie01@baidu.com>
Signed-off-by: Sean Owen <srowen@gmail.com>
bithium pushed a commit to bithium/protobuf that referenced this pull request Sep 4, 2023
fix serialization warnings in generated code when compiling with Java 18 and above
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

compiler serial warnings when compiling generated source with Java 18
5 participants