Whenever I needed to transmit Java objects, assuming similar JVM versions, I always used plain Java serialization (Sun official tutorial): it's simpler and you don't have to care about transmit chains of items or aggregates because serialization already cares about it (if you implement it correctly).
So if you want to transmit a complex object made by many sub-objects you don't have to split it, send it and recompose it: you just send the object and it already contains everything that was already included.
EDIT
About RMI: I used it together with serialization and it worked like a charm! I used to develop remote swing (sending JPanels over TCP)..
RMI can help you in calling remote methods and obtaining objects from a master server
Clients can use serialization (over a different socket) to send back objects or pass them as parameters to RMI invocation, this should be personal preference
Of course I don't know what exactly you want to do but both tools work great and can also be used orthogonally.
I know this thread is old now, but I just came across it and figured I'd throw in my 2 cents for the benefit of future readers...
Unless JSON is required for some reason, there is really no need for 2 applications to communicate using it. I agree with the Avro suggestions above. Avro lets you write business logic code and it deals with the serializing/deserializing for you. It will generate a server-side interface to implement (based on a schema you provide) and a client proxy stub to call the service through. It can serialize to other formats if needed too.
There isn't much for guiding documentation or examples out there, but here are a couple decent looking ones:
I'd recommend using Avro with the JSON encoding; you'll get the versioning support you need while still using HTTP and JSON, and you won't have to write the serialization/de-serialization code yourself. See http://hadoop.apache.org/avro/docs/current/spec.html for a concise description of the features of Avro, and drop a note to the mailing list or join the #avro channel on Freenode if you have any troubles getting started.
If you need to do this over public networks, use the json http approach, as you will not run into firewall issues - you can go over port 80
If your on an intranet the fastest way to do this (from a setup & maintainability point of view) is probably old fashioned Java rmi, which just requires you to define your remote interfaces and connect to an rmi server, you can be up and running in a few minutes and make ongoing changes to your remote objects/services without much fuss. Under the hood this just uses java serialisation
If your needs are performance sensitive (low latency, high throughput) you could use something like google protocol buffers
Also check out the Externalizable interface for custom serialisation
制作一个可以返回所需 Java 对象的 Web 服务会更有意义。那么你就不需要担心序列化/反序列化它。
Why JSON? That is typically used for web applications.
It would make more sense to make a web service which can return the Java object required. Then you don't need to worry about serializing/deserializing it.
You choices are divided between data only solutions and data plus behavior solutions.
For data, you can use JSON or you can use Java's serialization. JSON is simple but you'll have to roll your own class wrappers. Using Java's serialization can work well because the marshalling issues are well-known and handled in a consistent manner. A variation of this would be providing the Java class on both the local and remote systems but if you're doing that you might as well go on and do RMI. RMI is nice because you don't have to write a separate class for the remote end, but you do have watch out for some gotcha's when distributing objects, like making sure you set the Serial ID of the class or having to distribute the exact binary class file to the remote system. You could do it with RPC but if you're going that far, you might as well create a web service and use SOAP.
Over the years I have tried quite a few options or serialization/deserialization, including JSON, XML, SOAP, protobuf and some others I am embarrassed to name here :-)
Right now we are using JSON encoding almost exclusively for both Java-to-Java and JS-to-Java transfers, and even for storing internal data (unless the amount of binary data makes the JSON format too inefficient). The advantages of JSON are simplicity, light weight, both in terms of payload and the implementation complexity and availability of serialization solutions in all languages we have touched. It also helps to have "standard" persistence framework.
Lately Jackson has been working out well for us. Jabsorb also has good (de)serialization package.
Versioning: JSON has no built-in versioning support (Avro may have something), so you have to run your own. It is usually good idea to keep major/minor version numbering scheme: major version numbers are incompatible, minors are backward-compatible so that client 1.2 can talk to server 1.5 but not to server 2.1.
Gotchas:
It is sometimes challenging to convert Java generics, like TreeMap.
Some implementations may embed implementation class names by default which makes the protocol less change-resistant. You may want to make nothing redundant goes on the wire.
发布评论
评论（8）
每当我需要传输 Java 对象时，假设有类似的 JVM 版本，我总是使用纯 Java 序列化 (Sun官方教程）：它更简单，您不必关心项目或聚合的传输链，因为序列化已经关心它（如果您正确实现它）。
因此，如果您想传输由许多子对象组成的复杂对象，则不必拆分它、发送它并重新组合它：您只需发送该对象，它就已经包含了已包含的所有内容。
编辑
关于RMI：我将它与序列化一起使用，它的工作方式非常神奇！我曾经开发远程摆动（通过 TCP 发送 JPanel）。RMI
当然我不知道你到底想做什么，但这两个工具都很好用，也可以正交使用。
Whenever I needed to transmit Java objects, assuming similar JVM versions, I always used plain Java serialization (Sun official tutorial): it's simpler and you don't have to care about transmit chains of items or aggregates because serialization already cares about it (if you implement it correctly).
So if you want to transmit a complex object made by many sub-objects you don't have to split it, send it and recompose it: you just send the object and it already contains everything that was already included.
EDIT
About RMI: I used it together with serialization and it worked like a charm! I used to develop remote swing (sending JPanels over TCP)..
Of course I don't know what exactly you want to do but both tools work great and can also be used orthogonally.
如果两端都是Java写的，就用Java自己的序列化即可。
另一方面，使用 JSON、XML 或 YAML 将使调试变得更容易，因为传输的内容是可读的。
If both ends are written in Java, just use Java's own serialization.
On the other hand, using JSON, XML or YAML will make it easier to debug as what gets transmitted will be readable.
我知道这个线程现在已经很旧了，但我刚刚遇到它，并想我会为了未来读者的利益而投入 2 美分......
除非由于某种原因需要 JSON，否则确实不需要 2 个应用程序来使用它进行交流。我同意上面 Avro 的建议。 Avro 允许您编写业务逻辑代码，并为您处理序列化/反序列化。它将生成一个要实现的服务器端接口（基于您提供的架构）和一个用于调用服务的客户端代理存根。如果需要，它也可以序列化为其他格式。
那里没有太多指导文档或示例，但这里有一些看起来不错的文档或示例：
这是使用套接字服务器的教程：
http://gbif.blogspot.com/2011/06 /getting-started-with-avro-rpc.html
这是一个通过 http 使用 Avro 的开源项目/演示：
http://code.google.com/p/avro-http-example/
I know this thread is old now, but I just came across it and figured I'd throw in my 2 cents for the benefit of future readers...
Unless JSON is required for some reason, there is really no need for 2 applications to communicate using it. I agree with the Avro suggestions above. Avro lets you write business logic code and it deals with the serializing/deserializing for you. It will generate a server-side interface to implement (based on a schema you provide) and a client proxy stub to call the service through. It can serialize to other formats if needed too.
There isn't much for guiding documentation or examples out there, but here are a couple decent looking ones:
Here's a tutorial for using the socket server:
http://gbif.blogspot.com/2011/06/getting-started-with-avro-rpc.html
Here's an open source project/demo for using Avro over http:
http://code.google.com/p/avro-http-example/
我建议使用 Avro 和 JSON 编码；您将在仍然使用 HTTP 和 JSON 的同时获得所需的版本控制支持，并且无需自己编写序列化/反序列化代码。请参阅 http://hadoop.apache.org/avro/docs/current/spec .html 获取 Avro 功能的简明描述，如果您在入门时遇到任何问题，请在邮件列表中留言或加入 Freenode 上的 #avro 频道。
I'd recommend using Avro with the JSON encoding; you'll get the versioning support you need while still using HTTP and JSON, and you won't have to write the serialization/de-serialization code yourself. See http://hadoop.apache.org/avro/docs/current/spec.html for a concise description of the features of Avro, and drop a note to the mailing list or join the #avro channel on Freenode if you have any troubles getting started.
一些选项：
Some options:
为什么选择 JSON？这通常用于 Web 应用程序。
制作一个可以返回所需 Java 对象的 Web 服务会更有意义。那么你就不需要担心序列化/反序列化它。
Why JSON? That is typically used for web applications.
It would make more sense to make a web service which can return the Java object required. Then you don't need to worry about serializing/deserializing it.
您的选择分为纯数据解决方案和数据加行为解决方案。
对于数据，您可以使用JSON，也可以使用Java 的序列化。 JSON 很简单，但您必须推出自己的类包装器。使用 Java 的序列化可以很好地工作，因为编组问题是众所周知的并且可以以一致的方式处理。这种情况的一种变体是在本地和远程系统上提供 Java 类，但如果您这样做，您也可以继续执行RMI。 RMI 很好，因为您不必为远程端编写单独的类，但是在分发对象时您必须注意一些问题，例如确保设置类的序列 ID或者必须将精确的二进制类文件分发到远程系统。您可以使用 RPC 来完成此操作，但如果您想做到这一点，您不妨创建一个 Web 服务并使用 SOAP。
You choices are divided between data only solutions and data plus behavior solutions.
For data, you can use JSON or you can use Java's serialization. JSON is simple but you'll have to roll your own class wrappers. Using Java's serialization can work well because the marshalling issues are well-known and handled in a consistent manner. A variation of this would be providing the Java class on both the local and remote systems but if you're doing that you might as well go on and do RMI. RMI is nice because you don't have to write a separate class for the remote end, but you do have watch out for some gotcha's when distributing objects, like making sure you set the Serial ID of the class or having to distribute the exact binary class file to the remote system. You could do it with RPC but if you're going that far, you might as well create a web service and use SOAP.
多年来，我尝试了相当多的选项或序列化/反序列化，包括 JSON、XML、SOAP、protobuf 和其他一些我不好意思在这里命名的选项 :-)
现在，我们几乎专门将 JSON 编码用于 Java 到 - Java 和 JS-to-Java 传输，甚至用于存储内部数据（除非二进制数据量使 JSON 格式效率太低）。 JSON 的优点是简单、轻量，无论是在有效负载还是在我们接触过的所有语言的序列化解决方案的实现复杂性和可用性方面。它还有助于拥有“标准”持久性框架。
最近，Jackson 对我们来说表现得很好。 Jabsorb 也有很好的（反）序列化包。
版本控制： JSON 没有内置版本控制支持（Avro 可能有某事），所以你必须运行自己的。保留主要/次要版本编号方案通常是个好主意：主要版本号不兼容，次要版本号向后兼容，以便客户端 1.2 可以与服务器 1.5 通信，但不能与服务器 2.1 通信。
陷阱：
Over the years I have tried quite a few options or serialization/deserialization, including JSON, XML, SOAP, protobuf and some others I am embarrassed to name here :-)
Right now we are using JSON encoding almost exclusively for both Java-to-Java and JS-to-Java transfers, and even for storing internal data (unless the amount of binary data makes the JSON format too inefficient). The advantages of JSON are simplicity, light weight, both in terms of payload and the implementation complexity and availability of serialization solutions in all languages we have touched. It also helps to have "standard" persistence framework.
Lately Jackson has been working out well for us. Jabsorb also has good (de)serialization package.
Versioning: JSON has no built-in versioning support (Avro may have something), so you have to run your own. It is usually good idea to keep major/minor version numbering scheme: major version numbers are incompatible, minors are backward-compatible so that client 1.2 can talk to server 1.5 but not to server 2.1.
Gotchas: