Unable to serialize AtomicBoolean
on Java 17
#7270
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
See jenkinsci/docker-plugin#905. A few plugins, most notably the Docker plugin, attempt to serialize an
AtomicBoolean
via XStream. Under Java 11, this resulted in an "illegal reflective access operation has occurred" warning, while on Java 17 this results in "java.lang.reflect.InaccessibleObjectException
: Unable to make fieldprivate static final long java.util.concurrent.atomic.AtomicBoolean.serialVersionUID
accessible: modulejava.base
does notopens java.util.concurrent.atomic
to unnamed module", as shown when running the new test added in this PR without the changes tocore/src/main
:Java 11
Java 17
Evaluation
Filed upstream as x-stream/xstream#308. XStream has no built-in awareness of the
AtomicBoolean
type, so it uses reflection to serialize each of its fields. This breaks down on Java 17, where theserialVersionUID
field is not accessible. It is arguably preferable for plugins to serialize a plainboolean
rather than anAtomicBoolean
, but given the presence ofjenkins/core/src/main/resources/jenkins/security/whitelisted-classes.txt
Line 131 in 6448700
Solution
While we could open the
java.util.concurrent
module, we would rather not, since it generally indicates a code smell whereas usages should be ideally rewritten to use a non-concurrent data type. This change gets the affected plugins working again without precluding the long-term improvement of migrating those plugins away fromAtomicBoolean
.Implementation
This PR implements a custom converter for
AtomicBoolean
that serializes to the same on-disk format as that implicitly used by the reflection-based serializer that works in Java 11. This same converter was submitted to XStream in x-stream/xstream#309. Since that pull request has remained unacknowledged for over a month, I am adding the converter to Jenkins in the meantime.Future work
When the upstream change is merged and released, and when we upgrade to that release, this custom converter can be removed. If for some reason the custom converter is found to be problematic, this PR can be reverted at any time without compatibility issues, because the on-disk format remains unchanged.
Testing done
Integration testing
With the changes to
core/src/main/java
, the new test now passes without any warnings on both Java 11 and Java 17:Functional testing
I ran a Docker build on Java 17 before and after this PR. Before this PR, the build failed as in jenkinsci/docker-plugin#905. After this PR, the build passed.
Proposed changelog entries
Allow serialization of atomic boolean data types on Java 17.
Proposed upgrade guidelines
N/A
Submitter checklist
@Restricted
or have@since TODO
Javadocs, as appropriate.@Deprecated(since = "TODO")
or@Deprecated(forRemoval = true, since = "TODO")
, if applicable.eval
to ease future introduction of Content Security Policy (CSP) directives (see documentation).Desired reviewers
@mention
Maintainer checklist
Before the changes are marked as
ready-for-merge
:upgrade-guide-needed
label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).lts-candidate
to be considered (see query).