目前，我们使用 XStream 以 XML 形式对 Web 服务输入/输出进行编码。然而，我们正在考虑切换到带有多种语言（protobuf、Thrift、Hessian 等）代码生成器的二进制格式，以便更轻松地支持新客户端并减少对手动编码的依赖（也是为了更好地支持包含二进制数据的消息格式） 。
然而，服务器上的大多数对象都是 POJO，XStream 通过反射和注释处理序列化，并且大多数这些库假设它们将自己生成 POJO。我可以想到几种连接替代库的方法：
-
为目标格式编写 XStream 封送拆收器。
-
编写自定义代码以将 POJO 编组到替代库生成的类或从替代库生成的类编组 POJO。
编写自定义代码以将
-
子类化生成的类以实现 POJO 逻辑。可能需要一些重写。 （我是否还提到过我们要使用 Terracotta？）
-
使用另一个同时支持反射（如 XStream）和代码生成的库。
但是我不确定序列化库将是最适合上述技术。
We currently use XStream for encoding our web service inputs/outputs in XML. However we are considering switching to a binary format with code generator for multiple languages (protobuf, Thrift, Hessian, etc) to make supporting new clients easier and less reliant on hand-coding (also to better support our message formats which include binary data).
However most of our objects on the server are POJOs with XStream handling the serialization via reflection and annotations, and most of these libraries assume they will be generating the POJOs themselves. I can think of a few ways to interface an alternative library:
-
Write an XStream marshaler for the target format.
-
Write custom code to marshal the POJOs to/from the classes generated by the alternative library.
-
Subclass the generated classes to implement the POJO logic. May require some rewriting. (Also did I mention we want to use Terracotta?)
-
Use another library that supports both reflection (like XStream) and code generation.
However I'm not sure which serialization library would be best suited to the above techniques.
发布评论
评论（1）
(1) 可能不需要那么多工作，因为许多序列化库都包含知道如何读/写原始值和分隔符的帮助程序 API。
(2) 可能为您提供最广泛的工具选择： https://github.com/eishay /jvm-serializers/wiki/ToolBehavior（有些是语言中立的）。有缺陷但希望不是完全无用的基准： https://github.com/eishay/jvm-serializers/wiki
其中许多工具都会生成类，这需要编写代码来与 POJO 进行转换。直接使用 POJO 的工具通常不是语言中立的。
(3) 似乎是一个坏主意（不了解您的具体项目）。我通常让我的消息类不受任何其他逻辑的影响。
(4) Protostuff 库（支持 Protocol Buffer 格式）让您编写一个“架构”来描述您希望如何序列化 POJO。但是，与仅仅编写在 POJO 和某些工具生成的类之间进行转换的代码相比，编写此架构可能会需要更多工作，并且更容易出错。
Protostuff 还可以通过反射自动生成架构，但这可能会产生消息格式感觉有点以 Java 为中心。
(1) might not be that much work since many serialization libraries include a helper API that knows how to read/write primitive values and delimiters.
(2) probably gives you the widest choice of tools: https://github.com/eishay/jvm-serializers/wiki/ToolBehavior (some are language-neutral). Flawed but hopefully not totally useless benchmarks: https://github.com/eishay/jvm-serializers/wiki
Many of these tools generate classes, which would require writing code to convert to/from your POJOs. Tools that work with POJOs directly typically aren't language-neutral.
(3) seems like a bad idea (not knowing anything about your specific project). I normally keep my message classes free of any other logic.
(4) The Protostuff library (which supports the Protocol Buffer format) lets you write a "schema" to describe how you want your POJOs serialized. But writing this schema might end up being more work and more error-prone than just writing code to convert between your POJOs and some tool's generated classes.
Protostuff can also automatically generate a schema via reflection, but this might yield a message format that feels a bit Java-centric.