如何调试/查看 ObjectInputStream 数据？
我有一个 javaagent 使用 agentmain 连接到远程进程，它通过套接字将序列化的 java 对象发送到客户端应用程序。
流的格式似乎存在错误，我不确定这是否是我的 writeExternal 实现中的错误，或者是否与 java 版本有关。我正在尝试 java 1.6 32 / 64 位的不同组合。
基本上，对象流抛出一个类未找到异常，但打印的包名称类似于 org.mycode.beb，beb 部分与我拥有的任何包无关，我已经搜索遍了，但我的包中没有任何内容带有该字符串的代码或库... beb
所以我怀疑这是由编码格式差异或 32/64 位字长问题引起的编码问题，但我在这些领域没有那么丰富的经验。
我很习惯打开调试器来跟踪代码问题，但在诊断这种性质的问题（使用序列化和字节格式）方面经验不足，所以我想看看推荐的调试方法是什么？
我有客户端的控制/编译/源代码，它使用如下代码：
objectInput = new ObjectInput(inputStream);
Object object = objectInput.readObject();
当前抛出未找到 org.mycode.beb 的类
我正在考虑重写它以将序列化流存储到文件中并看一下（不是确定文件在读取时实际上采用什么格式），这是正确的角度吗？
I have a javaagent attached to a remote process using agentmain which sends serialized java objects via socket to a client application.
There appears to be a bug in the formatting of the stream which I am not sure if it is an error in my writeExternal implementation or if it is something to do with the java versions. I am experimenting with different combinations of java 1.6 32 / 64 bits.
Basically the object stream is throwing a class not found exception, but the package name printed is something like org.mycode.b.e.b., the b.e.b part is nothing to do with any packages I own and I have searched all over and there is nothing in my code or libraries with that string... b.e.b.
So I am suspicious it is an encoding issue caused by either a encoding format discrepancy or a 32/64 bit word length issue, but I am not that experienced in these areas.
I am quite used to opening up the debugger to track down code issues, but less experienced diagnosing problems of this nature, with serialization and byte formats so I am asking to see what are the recommended approaches to debugging?
I have control/compilation/source of the client which uses code like:
objectInput = new ObjectInput(inputStream);
Object object = objectInput.readObject();
which currently throws class not found for the org.mycode.b.e.b.
I was thinking about re-writing it to store the serialized stream to a file and taking a look ( not sure what format the file will actually be in in regard to reading it), is that the right angle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论您使用 32 位还是 64 位、大端机还是小端机，ObjectOutputStream 的格式都保持不变。过去出现问题的地方是 Java 1.3 和 Java 1.4 使用稍微不同的格式。此外，Eclipse 和 Sun 使用不同的算法来生成serialVersionUID，因此如果您没有对其进行硬编码，则可能会遇到问题。
但是，如果您有像 beb 这样的软件包，您很可能已经混淆了您的代码，其设计目的是使其难以使用。我建议您只调试/监视未混淆的代码。
The format for ObjectOutputStream is unchanged whether you use 32-bit or 64-bit or a big endian or little endian machine. Where there have been problems in the past has been between Java 1.3 and Java 1.4 using slightly different formats. Also Eclipse and Sun used different algos to generate serialVersionUID so you can run into problems if you didn't hard code it.
However if you have packages like b.e.b you most likely have obfuscated your code which is designed to make it difficult to work with. I suggest you only debug/monitor your un-obfuscated code.
我还要赞扬@Peter Lawrey。
我认为为了简化调试，您应该使用非混淆代码。这至少会给您提示问题所在。
此外，部分混淆的事实可能是问题的根本原因。想想：你的对象在客户端被序列化，没有被混淆。假设您的名为 MyFirstClass 的类依赖于 MySecondClass 并相应地进行序列化。但在服务器端，MySecondClass 名为 q。为什么是q？这取决于混淆器。此外，每个版本的该名称可能不同。因此，服务器端找不到类MySecondClass。
其他可能的问题是serialiVersionUID。也许您必须为所有相关类定义此变量并处理其值。
但首先要避免混淆，然后再试一次。我相信一切都会成功。祝你好运。
I addition to commend of @Peter Lawrey.
I think that to simplify your debugging you should work with non-obfuscated code. This will give you at least the tip where the problem is.
Moreover probably the fact of partial obfuscation is the root cause of your problem. Think: you object is serialized on client side that is not obfuscated. Let's say your class named MyFirstClass depends on MySecondClass and is serialized accordingly. But on server side the MySecondClass is named q. Why q? This is up to obfuscator. Moreover this name may be different for each build. So, the server side cannot find the class MySecondClass.
Other possible problem is serialiVersionUID. Probably you have to define this variable for all relevant classes and handle its value.
But first just avoid obfuscation and try again. I believe everything will work. Good luck.