Java XML-RPC 和原始类型

Question

我一直在研究 XML-RPC 在 Java 中的实现。主要的开源库(例如 Apache XML-RPC)使用原始类型来表示 Java 中的某些 XML-RPC 类型，例如结构体表示为原始映射。

Java 中不鼓励使用新代码中的原始类型。来自 JLS，

The use of raw types is allowed only as a concession to compatibility of legacy code. The use of raw types in code written after the introduction of genericity into the Java programming language is strongly discouraged. It is possible that future versions of the Java programming language will disallow the use of raw types.

但是，由于 XML-RPC protocol 的性质，在这种情况下原始类型是不可避免的吗？

Answer 1

给出 Structs 的 XML-RPC 示例:

<struct>
  <member>
    <name>submitter</name>
    <value><string>Deep Thought</string></value>
  </member>
  <member>
    <name>answer</name>
    <value><i4>42</i4></value>
  </member>
</struct>

...和数组:

<array>
  <data>
    <value><string>Don't Panic</string></value>
    <value><boolean>0</boolean></value>
    <value><dateTime.iso8601>19791012T12:24:42</dateTime.iso8601></value>
  </data>
</array>

您可以看到，根据规范，它们可以在同一结构中混合数据类型。这是泛型通常要避免的事情。由于 XML-RPC 支持的数据类型很广，与所有这些数据类型兼容的唯一公共(public)父类(super class)最终成为可靠的、旧的 java.lang.Object。 -- 与从原始集合中获得的类型相同。

我认为从技术上讲，你的问题的答案是:不，原始类型并非完全不可避免。然而，由于java.lang.Object作为最大的共同点，更改 Java5 之前的 API 可能没有什么实际的优势，因为原始集合类型为您提供 Object就这样。

出于争论的目的，让我们看看可以采取什么措施来引入泛型。首先，几乎可以肯定，这对使用以前版本的库(例如 Apache 的实现)的代码来说是一个破坏 API 的更改(与二进制 API 不兼容)。

接下来，结构将从原始 Map 更改为在这种情况下我们可以用泛型做到最好:Map<String, Object> 。立即，您不再需要将 key 转换到 String以便以某种方式确定您是否关心相关的值。但在大多数重要情况下，根据程序逻辑，该值仍然需要进行一些转换。

与结构类似，XML-RPC 数组可以从原始 List 切换至List<Object> ，但这实际上对程序逻辑没有任何影响。没有额外的元数据(例如结构体的 String 字段名称)来使这一点变得有利。

更糟糕的是，这两个数据结构都可以相互嵌套。这样Object您从一个映射值(或数组/列表元素)获得的可能是另一个 List或Map -- 在这种情况下甚至转换到 List<Object>或Map<String, Object>分别会吐出大量 unchecked cast警告。

就实用性而言，只要 API 用于处理或内省(introspection)任意 XML-RPC 数据结构，是的原始类型可能是不可避免的。或者不值得避免。 (在很多方面，考虑到编译时类型删除，这与反射和序列化是一个类似的挑战。)

现在，一线希望是这样的库有可能支持将这些非常通用的 XML-RPC 数据结构编码到您为特定应用程序定义的特定强类型类或从这些类编码。但是，如果您有一个支持该路线的库，希望您不再直接处理结构/数组表示。 (或者，如果是的话，希望您的数据模型不会在同一个“数组”中混合不同的值类型。)

希望对您有所帮助。