我正在研究一些代表 XML 元素的 Java 对象。因为我目前使用的标准可能会变得有点笨拙，所以我正在设计包含许多 JAXB 对象（直接从 .xsd 生成）的组合，并提供附加功能以方便使用。
由于我在 Java 中表示的对象是实际的 XML 对象，将它们序列化为 XML 是否合适？如果不是，为什么这是一个坏主意（除了性能原因）？
编辑：
我收到了一些“你为什么要这样做？” 输入问题，让我解释一下。当对象的逻辑实现与其物理实现有很大不同时（来自 Bloch 的 Effective Java，第 75 条），考虑自定义序列化形式通常是合适的。在我的情况下，物理形式将与逻辑形式有很大不同，并且自定义序列表示是合适的。由于该对象总是能够由 XML 表示，因此在逻辑上看起来很合适，但我试图理解这对 Java 语言（IE 性能）的影响。
我怀疑这是一个好主意。xml 表示可能需要大约 100 倍于二进制代表所需的空间。在我使用 xml 文档序列化之前，我会使用 java std 序列化。（舒适但不高效）
更适合的是一些二进制 xml 表示。像 BSON for JSon 或 Google protobuf。寻找二进制 XML。
由于我在 Java 中表示的对象是实际的 XML 对象，将它们序列化为 XML 是否合适？
我假设您的意思是 DOM 之类的东西。然后您使用一些 XML 绑定进行序列化......将 DOM 对象视为 POJO ！
坏主意，海事组织。
如果不是，为什么这是一个坏主意（除了性能原因）？
实际上，我正在努力思考这可能是个好主意的任何原因。
更新
您对为什么这样做的解释（在您的更新/评论中）没有说服力：
当对象的逻辑实现与其物理实现有很大不同时（来自 Bloch 的 Effective Java，第 75 条），考虑自定义序列化形式通常是合适的。
Bloch 的建议是考虑使用自定义表示。其中隐含的假设是，您认为自定义表示比您面前的标准表示更好。
在我的情况下，物理形式将与逻辑形式有很大不同，并且自定义序列表示是合适的。
这并不能解释为什么您首先要在 XML 中表示 DOM。或者为什么你认为它更好。
由于该对象总是能够由 XML 表示，因此在逻辑上看起来很合适，...
你没有解释这个逻辑。
...但我试图理解这对 Java 语言（IE 性能）的影响。
那么影响就像我上面解释的那样。Java 对此并没有什么特别之处。
好的，让我们从另一个角度来看这个。
您最终会得到一个 Java 对象的 XML 表示，这些对象表示一些表示您的原始信息的 XML。
这比原始信息的 XML 表示形式更好吗？
现在，也许，如果在步骤 3 中您使用了 jaxb 并反序列化为自定义 Java 类……那么将这些 Java 类序列化为有意义。但是你没有“代表 XML 元素的 Java 对象”。相反，您拥有表示原始 XML 所表示的信息的 Java 对象。
这与您在问题中实际写的内容完全不同。如果这就是你的意思，它解释了为什么人们不理解你......并且认为你实际上说的话几乎没有意义。
您的意思是序列化为 XML 文件吗？一般认为，出于性能原因，这不是一个好主意，但是如果您打算将这些对象/xml 文件用作另一个系统的提要，那么可能值得考虑
如果您主要关心的是能够验证对象是否符合 XSD 中定义的规则，那么这是一个如何工作的链接。鉴于此，请注意将对象编组为 XML 将花费您一些周期。对性能的重大影响之一是创建将用于编组对象的 JAXB 上下文。您可以通过在某种单例对象（POJO、Spring bean 等）中创建 JAXB 上下文来最小化这种性能损失，这样就不会每次都重新创建它。