Introduce new immutable protocol #8945
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
npepinpe
force-pushed
the
8837-record-copyof
branch
from
e1c0fe7
to
88bd57b
Compare
npepinpe
force-pushed
the
8837-immutable-protocol
branch
2 times, most recently
from
13ccb2e
to
5ed71b9
Compare
|
bors merge |
|
bors r- |
|
Canceled. |
|
I think it might be better to postpone this for the next release, primarily because this will cause additional effort for the Operate team which is already using this, and I will check in with them, and if they tell me it's fine we can go ahead anyway, but let's see. |
Adds immutable protocol generation to the Zeebe record protocol. This is done via an annotation process, Immutables, which requires two annotations on each leaf types: - `@Value.Immutable` - `@ImmutableProtocol` All leaf types - that is, types expected to have a single, direct, concrete implementations - need to be annotated with both values to ensure that there is always one immutable variant available, especially for deserialization. Meta-types such as `ProcessInstanceRelated`, for example, do not need to be annotated but can be left as is. This may of course change in the future. This commit is the first step to removing the immutable protocol from protocol-jackson, but for now both are existing at the same time.
Generates flat assertions for each protocol type as opposed to hierarchical ones, omitting generated immutable variants. This should solve some compile time issues related to code generation, and simplify usage. No more need to use RecordValueWithVariables.hasVariables when dealing with a JobRecordValue - instead you can keep using `JobRecordValueAssert.hasVariables`.
Adds an ArchUnit tests which ensures all protocol leaf types are annotated, guaranteeing an immutable variant will be generated for each of these types. At the moment, this means `Record` and type under `record.value` package or one of its sub-packages, except `ProcessInstanceRelated`.
npepinpe
force-pushed
the
8837-immutable-protocol
branch
from
5ed71b9
to
b1bfc42
Compare
|
bors merge |
|
Build succeeded:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Introduces a new immutable protocol directly under
protocol, which annotates the types directly. This has several advantages:Record, which is a special case due to its generic typing)This is the first step for #8837 - the next step will remove the immutable variants in
protocol-jacksonand replace them with this.Related issues
related to #8837
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
backport stable/1.3) to the PR, in case that fails you need to create backports manually.Testing:
Documentation: