时间戳

首页 > 解决方案 > 为什么很多类的方法和接口都没有在JSR文档中定义

java - 为什么很多类的方法和接口都没有在JSR文档中定义

问题描述

我正在寻找一个 java 项目，它可以让我只查看规范并在 java 中实现解决方案。我想我会看看 JSR-173-Streaming-API-for-XML 规范。并认为所有类/接口定义以及类方法都将在此处详细描述。这个规范并没有像我想象的那样定义每个类和方法。

我在名为 jsr173_1.0.pdf 的 .pdf 文件中的以下 URL https://jcp.org/aboutJava/communityprocess/final/jsr173/index.html找到了规范。

规范提到包 javax.xml.stream，所以我认为该包中的所有 API 都将在规范中明确定义。

例如，在规范中。我找到了 javax.xml.stream.XMLOutputFactory 类，但它只提到了其中一个方法 newInstance()，没有提到该类的其他 14 种方法。

甚至没有提到 javax.xml.stream 包中的 FactoryConfigurationError 和 EventFilter 等其他接口和错误。

所以我的问题是，如果不在规范中。它在哪里指定此 API 的所有其他类方法和接口。

谢谢你。

标签： java

解决方案

为什么很多类的方法和接口都没有在JSR文档中定义

首先是一些事实。

  • Java 1.0 于 1996 年发布。
  • JSR 流程建立于 1998 年（来源）
  • 第一批 JSR 在 2000 年左右产生了公共审查草案。

在 JSR 流程建立时，核心 Java API 已经成熟。他们不需要（或被认为不需要）重大修订，因此没有必要建立 JSR。

如果无事可做，人们不会成立委员会等等。如果客观上不需要，人们不会编写和发布正式的规范文件......

其次，在 1996 年到 2000 年期间发生的一些重要的 Java 变化（例如 Swing、Collections）是在 Sun 内部驱动的。您需要询问相关人员的真正原因是什么，但我怀疑这是以下原因的组合：

  • JSR 和其他生成规范的过程是通过达成共识来完成的。这是一个迭代过程。参与的人和组织越多，所需的时间就越长。在某些情况下，它会花费太长时间。

  • 当时 Sun Microsystems 中可能有人不希望非 Sun 人员过多地参与某些 API 的设计过程。无论出于何种原因。

最后，有（可能）更新的 API 或 API 更改的示例，其中不涉及 JSR。在某些情况下，这些更改可能是 JEP 的结果。在其他情况下，它们可能是 Sun 或 Oracle 内部决定在没有任何（正式）外部输入的情况下实施功能或更改的结果。他们有权做那种事情（并且可能仍然做）。

所以我的问题是，如果不在规范中。它在哪里指定此 API 的所有其他类方法和接口。

在这种情况下，规范是已发布的（例如 Java SE）javadocs。如果 javadocs 没有指定某些方面，那么发布的（OpenJDK 或其他参考实现）源代码将确定实际发生的情况或说明应该发生的情况。您可以下载并阅读它。

（请注意，（至少）javadocs 中未指定的 API 行为可能会发生变化。从历史上看，Java 团队一直小心避免会破坏针对旧（公共！）API 实现的应用程序的更改。但是最近有例外情况；例如，Applet 支持的弃用和删除。）

推荐阅读