feat(java): Support codegen for xlang serialization in java for strict mode #2312
Conversation
| @@ -240,6 +240,9 @@ public String genCode() { | |||
| ctx.addField(ctx.type(Fory.class), FORY_NAME); | |||
| Expression encodeExpr = buildEncodeExpression(); | |||
| Expression decodeExpr = buildDecodeExpression(); | |||
|
|
|||
| Expression xlangEncodeExpr = buildXlangEncodeExpression(); | |||
There was a problem hiding this comment.
we should do this only fury is configured to use xlang mode, and when using xlang mode, do not generate code for java native serialization, i.e. don't generate code for read/write
|
Could we add some unit tests for xlang jit mode? |
| @@ -123,6 +123,8 @@ public CodecBuilder(CodegenContext ctx, TypeRef<?> beanType) { | |||
| /** Returns an expression that serialize java bean of type {@link CodecBuilder#beanClass}. */ | |||
| public abstract Expression buildEncodeExpression(); | |||
|
|
|||
| public abstract Expression buildXlangEncodeExpression(); | |||
There was a problem hiding this comment.
Could we keep buildXlangEncodeExpression and buildXlangDecodeExpression in BaseObjectCodecBuilder.java?
| @@ -83,7 +84,7 @@ public class CrossLanguageTest extends ForyTestBase { | |||
|
|
|||
| @BeforeClass | |||
| public void isPyforyInstalled() { | |||
| TestUtils.verifyPyforyInstalled(); | |||
| // TestUtils.verifyPyforyInstalled(); | |||
There was a problem hiding this comment.
Seems this is unrelated to this PR, could we revert this change?
| @@ -798,4 +799,55 @@ public void testEnumField() throws java.io.IOException { | |||
| Assert.assertEquals(xserDe(fory, a), a); | |||
| structRoundBack(fory, a, "test_enum_field"); | |||
| } | |||
|
|
|||
| @Test | |||
| public void testCodeGen() { | |||
There was a problem hiding this comment.
Could we split it into two tests, one for SCHEMA_CONSISTENT, and another for COMPATIBLE.
And perhaps we could create a new test file CodegenXlangTest.java under org.apache.fory.xlang package, and move this test into that file. CrossLanguageTest is a little big currently
| import org.apache.fory.serializer.SerializationUtils; | ||
| import org.apache.fory.serializer.Serializer; | ||
| import org.apache.fory.serializer.Serializers; | ||
| import org.apache.fory.serializer.*; |
There was a problem hiding this comment.
Fory doesn't use * imports, please expand all imports
| addSerializer(cls, serializer, namespace, typeName, xtypeId); | ||
| } | ||
|
|
||
| /** Ass serializer for specified class. */ |
There was a problem hiding this comment.
what does ass means here?
| case SCHEMA_CONSISTENT: | ||
| return ObjectSerializer.class; | ||
| case COMPATIBLE: | ||
| return shareMeta ? ObjectSerializer.class : CompatibleSerializer.class; |
There was a problem hiding this comment.
CompatibleSerializer.class is not used for xlang serialization, we used meta shade mode for xlang forward/backward compatibility, CompatibleSerializer use kv format instead
There was a problem hiding this comment.
shareMeta ? MetaSharedSerializer.class : ObjectSerializer.class
is this correctly？
| sc = | ||
| fory.getJITContext() | ||
| .registerSerializerJITCallback( | ||
| () -> ObjectSerializer.class, |
There was a problem hiding this comment.
I prefer creating serializer lazily, since the hash compute for type meta will read names of all registered classes. And when class registration is invoked, if the serializer are created egaerly, some classes don't have a change to let the registered name/tag being used for hash computing
What does this PR do?
Related issues
#2286
Does this PR introduce any user-facing change?
Benchmark