Serialize and deserialize between the old and new versions of Fory are incompatible.

[lidothui]

Search before asking

• I had searched in the issues and found no similar issues.

Version

Fory 0.13.1

Component(s)

Java

Minimal reproduce step

I used 0.12.2 fory to serialize an UUID object, belows are the code snippets:

final Fory fory = Fory.builder()
        .withLanguage(Language.JAVA)
        .requireClassRegistration(false)
        .build();

final UUID uuid = UUID.fromString("45985b2a-87ba-4747-b5d6-21ab[45666596](tel:45666596)");
final byte[] bytes = fory.serialize(uuid);


final String filePath = "~/data.fory.uuid.0.12.2";
try (FileOutputStream fos = new FileOutputStream(filePath)) {
    fos.write(bytes);
}

Then I used 0.13.1 fory to deserialize, belows are the code snippets:

final Fory fory = Fory.builder()
        .withLanguage(Language.JAVA)
        .requireClassRegistration(false)
        .build();
final String filePath = "~/data.fory.uuid.0.12.2";
final byte[] readBytes = Files.readAllBytes(Path.of(filePath));

final UUID restored = fory.deserialize(readBytes, UUID.class);

The deserializing codes report the exception:

Exception in thread "main" org.apache.fory.exception.DeserializationException: Failed to deserialize input
        at org.apache.fory.util.ExceptionUtils.handleReadFailed(ExceptionUtils.java:66)
        at org.apache.fory.Fory.deserialize(Fory.java:892)
        at org.apache.fory.Fory.deserialize(Fory.java:805)
        at com.ruijie.rcos.dex.explorer.serializer.ForyFileExample.deserialize(ForyFileExample.java:80)
        at com.ruijie.rcos.dex.explorer.serializer.ForyFileExample.main(ForyFileExample.java:28)
Caused by: java.lang.IndexOutOfBoundsException: readerIndex(5) + length(2) exceeds size(20): org.apache.fory.memory.MemoryBuffer$BoundChecker@1750fbeb
        at org.apache.fory.memory.MemoryBuffer$BoundChecker.fillBuffer(MemoryBuffer.java:189)
        at org.apache.fory.memory.MemoryBuffer.checkReadableBytes(MemoryBuffer.java:2433)
        at org.apache.fory.serializer.StringSerializer.readBytesUnCompressedUTF16(StringSerializer.java:495)
        at org.apache.fory.serializer.StringSerializer.readBytesString(StringSerializer.java:199)
        at org.apache.fory.serializer.StringSerializer.readJavaString(StringSerializer.java:349)
        at org.apache.fory.Fory.readJavaString(Fory.java:774)
        at org.apache.fory.serializer.Serializers$RegexSerializer.read(Serializers.java:528)
        at org.apache.fory.serializer.Serializers$RegexSerializer.read(Serializers.java:515)
        at org.apache.fory.Fory.readDataInternal(Fory.java:1049)
        at org.apache.fory.Fory.readRef(Fory.java:934)
        at org.apache.fory.Fory.deserialize(Fory.java:888)
        ... 3 more

I used 0.12.2 Fory and 0.13.1 Fory to serialize the same UUID string, there is one difference (ac vs ae) in the hexdump files.

What did you expect to see?

Serialize and deserialize between the old and new versions of Fory Should be compatible.

What did you see instead?

Serialize and deserialize between the old and new versions of Fory are incompatible.

Anything Else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!

[CherishCai]

x.y.z 版本，好像跨 y 版本的 Fory 是不承诺兼容性的，可能做了什么不兼容改动吧，以负责人答复为准

[chaokunyang]

@lidothui Currenly fory don't provide binary compatibility between minor version. The 0.13.x is not compatible with 0.12.x for binary compatibility.

You can only get binary compatibility for fix version such as between 0.12.1 and 0.12.x

[ankyhe]

As a serialize/deserialize library, it is not a good idea for it doesn't keep binary compatibility even between minor versions. I hope you can consider carefully about this decision.

I can describe our scenario as below:

1. It has 2 micorserivces foo and bar. foo receives events from HTTP and sends records into Kafka;
2. bar reads records from Kafka
3. When we upgrade service foo and bar, it is probably there existing new version bar with 0.13.x fory deserializing records being serialized by an old version foo with 0.12.x fory.
   I have no idea how can we can handle this case so as we should change to use an alternative library.

[chaokunyang]

@ankyhe You may need to include a version header and bundle two versions of Fory during upgrades so the system can choose the correct version for deserialization. This avoids compatibility issues when one service is updated before the other.

We understand that binary compatibility is important. Full binary compatibility will be guaranteed starting from Fory 1.0. Before that, some breaking changes are still possible, even in minor version updates, because 0.x.x versions are not yet considered stable. We will still try to minimize such changes.

For Fory Java specifically, we have only a few tasks left before binary compatibility is fully stabilized:

1. Remove the key/value–based CompatibleSerializer and use the meta‑shared CompatibleSerializer for all serialization.
2. Make ObjectStreamSerializer use the meta‑shared CompatibleSerializer for every layer in the object inheritance chain.
3. Reserve 256 class IDs for Fory’s internal registry so user‑defined class IDs start from 0, with Fory adding 256 internally.

Once these are done, Java serialization will be stable at the binary level, and we will move toward the Fory 1.0 release.

That said, in most real‑world scenarios you do not need to upgrade Fory frequently. The current version is already feature‑complete enough for typical use cases.

[ankyhe]

Thanks for your feedback. We will consider fory after it is get stable. Do you have a plan when it will get to version 1.0?

That said, in most real‑world scenarios you do not need to upgrade Fory frequently. The current version is already feature‑complete enough for typical use cases.

Generally, we'd like upgrade 3rd party libraries every 2~3 months (excluding libraries used for test only). This has 2 advantages:

1. Some libraries may have security issue (CVE-xxxx) and new version fixes it.
2. If we upgrade a library for a long time, it increases upgrading time/cost/risk when we upgrade many libraries.