Skip to content

Conversation

@mchernyakov
Copy link

Why?

Based on the discussion #2786.
We can optimize the payload in cases where we have final fields in some Object.

re-created, closed PR #2904

What does this PR do?

Introduce FinalFieldReplaceResolver which does not write the classname into the payload.

Related issues

Does this PR introduce any user-facing change?

  • Does this PR introduce any public API change?
  • Does this PR introduce any binary protocol compatibility change?

Benchmark

@mchernyakov
Copy link
Author

@chaokunyang re-created my PR, addressed your comments in slack, please check

if (JavaSerializer.getWriteReplaceMethod(cls) != null) {
return ReplaceResolveSerializer.class;
if (!fory.isCompatible() && !fory.isShareMeta() && Modifier.isFinal(cls.getModifiers())) {
return FinalFieldReplaceResolveSerializer.class;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we can return this here? If FinalFieldReplaceResolveSerializer don't write class info, and fory don't write class into, then for deserialization, how do we know which class to use to create object instance?

Copy link
Collaborator

Choose a reason for hiding this comment

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

FinalFieldReplaceResolveSerializer can only be used for field serializer, and getSerializerClass is used for non-field object serialization too.

Another thing is that this change make all tests pass, it should not. We may need add a test to cover this

Copy link
Author

Choose a reason for hiding this comment

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

you're right. wdyt about 0645ed9 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants