feat(java): support xlang serialization for GraalVM native image #3126
+153
−13
Conversation
This file contains hidden or 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
Closes apache#3112 - Add XtypeResolver.ensureSerializersCompiled() to ensure serializers for xlang-registered classes are compiled at GraalVM build time - Update Fory.ensureSerializersCompiled() to also call XtypeResolver when xlang mode is enabled - Add XlangExample for graalvm_tests to verify xlang mode works with native-image builds - Register XlangExample for build-time initialization in native-image properties
GraalvmSupport.registerClass should be called for all classes, not just during GraalVM build time. Only the enum-specific handling should be guarded by isGraalBuildtime().
- Add abstract ensureSerializersCompiled() to TypeResolver - Add @OverRide to ClassResolver.ensureSerializersCompiled() - Have XtypeResolver.ensureSerializersCompiled() call classResolver first - Simplify Fory.ensureSerializersCompiled() to use _getTypeResolver()
This commit adds support for xlang (cross-language) serialization mode when running with GraalVM native image. Key changes: - Add "Xlang" suffix to generated codec class names to differentiate xlang and non-xlang codecs (BaseObjectCodecBuilder) - Use configHash in graalvmSerializers cache key to prevent codec reuse between xlang and non-xlang modes (CodecUtils) - Use TypeResolver interface instead of concrete class to support both xlang and non-xlang modes in generated code - Add xwrite/xread methods to GraalvmSerializerHolder for xlang support (GraalvmSupport) - Direct serializer creation in XtypeResolver.register for GraalVM build time to avoid DeferedLazySerializer persistence issues - Add resolveSerializer() method to DeferedLazySerializer for explicit resolution during ensureSerializersCompiled - Skip Lambda/Proxy serializers in xlang mode since java.lang.Class is not supported (ClassResolver) Closes apache#3112
pandalee99
approved these changes
Jan 12, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Closes #3112
This PR adds support for xlang serialization mode with GraalVM native image builds.
Changes:
XtypeResolver.ensureSerializersCompiled()to ensure serializers for xlang-registered classes are compiled at GraalVM build timeFory.ensureSerializersCompiled()to also callXtypeResolver.ensureSerializersCompiled()when xlang mode is enabledXlangExamplefor graalvm_tests to verify xlang mode works with native-image buildsXlangExamplefor build-time initialization in native-image propertiesRoot cause:
When xlang mode is enabled, classes registered via
Fory.register()go throughXtypeResolver, butFory.ensureSerializersCompiled()only processed classes inClassResolver.classInfoMap. This meant xlang-registered classes were not properly compiled at GraalVM build time, causing NullPointerException during initialization.Test plan