Java 中的 XML: 数据绑定，第 1 部分：代码生成方法 — JAXB 及其它

核心提示： 重新架构 JAXB直到 2002 年 3 月，新体系结构的细节才公布于众，Java 中的 XML: 数据绑定，第 1 部分：代码生成方法 — JAXB 及其它(5)，在 JavaOne 上，Sun 宣布，提供可选的特定于框架的支持，数据结构本身被更改为类 JavaBean 的数据对象，作为在 J

重新架构 JAXB

直到 2002 年 3 月，新体系结构的细节才公布于众，在 JavaOne 上，Sun 宣布，作为在 JAXB 方面进一步工作的基础，实际上正在放弃 EA 代码。它将被新设计所替代，在新设计中，共享了一些常见的功能，但新设计使用不兼容的 API 和内部体系结构。发展方向变化如此之大，让我和那些对 EA 代码有兴趣的人们感到惊讶。

JAXB 项目的 SUN JSR 负责人 Joseph Fialli 把这么大的变化归结为以下一些因素。主要问题是扩展原有代码库以支持 W3C XML Schema 的复杂性。这是一个相当复杂的规范，以至于在批准之后的两年多时间里，在所有平台上，仍然只有少数几个解析器能接近完全符合规范。最初的 JAXB 代码需要实际对象来控制验证，而且将这种方法扩展到 Schema 将耗费太多精力，以至于在合理的期限内无法实现这项工作。

为适应 Schema 而做出变更的同时，专家组还决定重新考虑处理验证的方法。原来的 JAXB 代码无条件地验证文档的结构，如果发现错误，则抛出异常并中止处理。Fialli 说，在公众的意见中，抱怨这种方法局限性太大、限制太严 ― 在一些情况下，用户希望能够一次检查多个验证错误，而在另一些情况下，则希望完全禁用验证（或者由于性能原因，或者在编组没有精确匹配文法的文档时）。新的 JAXB 体系结构能够满足这两种需求。

最后，专家组决定放弃单个绑定框架运行时（就象在原来 EA 发行版中所看的）的想法。而采用接口方法，其实质是可以使用不同的数据绑定框架。这使用户代码可以在各框架之间进行移植，而不需移植生成的类 ― 这些类特定于专门的数据绑定框架，它们只能由该框架运行。强制性的 SAX 2.0 解析器支持替代了 EA 运行时中所使用的拉解析器方法，对于其它解析器（可能包括新的拉解析器，该解析器基于用于 XML 的流式 API，JSR 173 正在定义此 API），提供可选的特定于框架的支持，数据结构本身被更改为类 JavaBean 的数据对象，外部框架可以方便地操作此数据对象。