[Java] when can I use Fury with buffer/storage in production

[smalljunHw]

The document says

We are still improving our protocols, binary compatibility are not ensured between fury releases for now. Please shade fury if you will upgrade fury in the future.
Binary compatibility will be ensured before fury 1.0.

So is Fury not recommended for production use now if any serialized object is stored in some place, otherwise future Fury release upgrade may cause deserialization problem?
If so, when binary compatibility will be ensured?

[chaokunyang]

Hi @smalljunHw , thanks for opening up this issue. There are three parts of work to be finished before we can ensure binary compatibility:

• Improve collection serialized size by using possiblely homogeneous information in collection elements Why does Fury serialized byte array significantly larger compared to Kryo? #912
• Improve map serialized size by using possiblely homogeneous information in map k/v items
• Implement meta share mode for type compatibility to reduce space cost of kv compatible mode nad improve performance of serialiation by at most 1x [Java] Meta shared mode serialization #80 .

I'm afraid binary compatibility can't be ensured before we finish this.

If you want to use it for persistent storage, you may need to add a version flag into the stored data, and shade fury by version, so in future you can switch to newer version of fury without breaking binary compatibility.

[chaokunyang]

@smalljunHw I add the doc for upgrade fury when breaking binary compatibility: https://github.com/alipay/fury/blob/main/docs/guide/java_object_graph_guide.md#upgrade-fury

If you use fury by this method, future Fury release upgrade won't cause deserialization problem. Does this answer your concern?

[Chenhaoqing]

Hi @chaokunyang , Can I use "versioning" to ensure binary compatibility now?

The description of

Binary compatibility will be ensured before fury 1.0.

from here is still a little unclear to me.

Thanks for the help.

[chaokunyang]

yes, if you serialize by https://github.com/alipay/fury/blob/main/docs/guide/java_object_graph_guide.md#upgrade-fury
The binary compatibility can be ensured:

[smalljunHw]

@smalljunHw I add the doc for upgrade fury when breaking binary compatibility: https://github.com/alipay/fury/blob/main/docs/guide/java_object_graph_guide.md#upgrade-fury

If you use fury by this method, future Fury release upgrade won't cause deserialization problem. Does this answer your concern?

thanks, it has answered my question.
I think binary compatiability is an import issue that needs to be solved as soon as possible. It may be odd without it.
By the way, according to https://stackoverflow.com/questions/65718/what-do-the-numbers-in-a-version-typically-represent-i-e-v1-9-0-1, for v0.2.1, the major version number is 0 instead of 2, 2 is actually the minor version.

[chaokunyang]

@smalljunHw Thanks for your reminder, the document should be updated for his version naming. As to binary compatiability, maybe we should add protocol version to data header, and develop a tool for future binary data migration.

Would you like to collaborate on this?

If we have protocol version on data, we can load different version of fury based on the protocol. The different fury can be shaded into different package. Or we can create a jar like springboot with a cusom format, and load different fury jar by different URLClassloader. Then use loaded Fury to deserialize the data