我一直在研究 Java 中 XML-RPC 的实现。主要的开源库（例如 Apache XML-RPC）使用原始类型来表示 Java 中的某些 XML-RPC 类型，例如结构表示为原始映射。
Java 不鼓励新代码中的原始类型。来自 JLS，
仅允许使用原始类型作为对遗留代码兼容性的让步。强烈反对在将泛型引入 Java 编程语言之后编写的代码中使用原始类型。 Java 编程语言的未来版本可能会禁止使用原始类型。
但是，由于XML-RPC protocol 的性质，在这种情况下，原始类型是不可避免的吗？
【问题讨论】：
鉴于 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 支持的数据类型的广度，唯一与所有这些兼容的通用超类最终是可信赖的、旧的 java.lang.Object —— 与您从原始集合中获得的相同类型。
从技术上讲，我认为您的问题的答案是：否，原始类型并非完全无法避免。然而，由于java.lang.Object 是最大的公分母，因此更改 Java5 之前的 API 可能几乎没有实际优势，因为原始集合类型为您提供了 Object。
为了论证的缘故，让我们看看无论如何可以做些什么来引入泛型。首先，它几乎可以肯定是对使用该库以前版本（例如 Apache 的实现）的代码的 API 破坏性更改（不兼容二进制 API）。
接下来，结构将从原始的Map 更改为在这种情况下我们可以用泛型做的最好的事情：Map<String, Object>。马上，您不再需要将密钥转换为 String 以某种方式确定您是否关心关联的值。但在大多数不平凡的情况下，该值仍需要根据程序逻辑进行一些转换。
与结构类似，XML-RPC 数组可以从原始的List 切换到List<Object>，但这实际上对程序逻辑没有影响。没有额外的元数据（如结构的 String 字段名称）可以使这变得有利。
更糟糕的是，这两种数据结构都可以相互嵌套。因此，您从其中一个映射值（或数组/列表元素）中获得的 Object 可能是另一个 List 或 Map - 在这种情况下，甚至分别转换为 List<Object> 或 Map<String, Object> 是会吐出一大堆unchecked cast 警告。
就实用性而言，就用于处理或内省任意 XML-RPC 数据结构的 API 而言，是的原始类型可能是不可避免的。或者不值得避免。 （在许多方面，就编译时类型擦除而言，这与反射和序列化类似。）
现在，一线希望是此类库有可能支持将这些非常通用的 XML-RPC 数据结构编组到您为特定应用程序定义的特定强类型类之间。但是，如果您有一个支持该路线的库，希望您不再直接处理结构/数组表示。 （或者如果你是，希望你的数据模型不会在同一个“数组”中混合不同的值类型。）
希望对你有帮助。
【讨论】：