"撤回"状态对JSR意味着什么？

Question

我正在检查JSR 227页面并查看其状态显示为"撤消".这个状态意味着什么？这是否意味着它被弃用了？是否有更新版本取代了此规范？

Answer 1

作为程序员,你没有任何意义.

Oracle为JSF应用程序的用户界面发明了一种声明性方式,以连接到底层数据服务,这是他们的应用程序开发框架(ADF)的核心.由于他们已经构建并在ADF中广泛使用它,并且由于他们将ADF用于他们庞大的新ERP套件(Fusion Applications),因此它将长期存在.

Oracle希望能够说出"基于标准",因此他们以JSR的形式提交了自己的方式.使用不同方法的IBM认为授予其竞争对手官方JSR没有任何好处,因此他们阻止了它.

它被撤回的事实只是家务管理.

Answer 2

来自JCP 流程文档，第 2.1 节：

根据 PMO 的要求，提交者可以在 JSR 投票完成之前撤回任何 JSR 提案，无需任何解释。

所以，这仅仅意味着它在批准之前被撤回，仅此而已。目前尚不清楚是否有替代品。该特定规范仅表明它“应规范负责人的要求撤回”，因此您需要联系 Oracle 的 John Smiljanic 以获取详细信息。

为了完整起见，阅读下面的JSR 评审投票评论可能会有所帮助。很可能 IBM 和 BEA 提出的担忧让 Oracle 相信，以目前的形式不值得追求，但这只是我的猜测（我想认为是有根据的）。

2003 年 6 月 25 日，Sun Microsystems, Inc. 投了赞成票，但没有发表评论。

2003 年 6 月 30 日，Oracle 投了赞成票，并发表了以下评论： Oracle 理解 IBM 的问题，但认为对该 JSR 的细节可能存在误解。该 JSR 的范围实际上相当小，并且仅限于能够进行任何绑定并将其移植到任何标准服务器所需的接口和格式。此功能的最低要求是声明性绑定和数据控制。他们各自为彼此而存在。该 JSR 的范围仅涵盖这些对象的接口，而不是具体的实现。这将是特定于供应商的。正如我们与许多其他 EC 成员所做的那样，Oracle 很乐意澄清该提案中的任何不清楚之处。

2003年6月27日，思科系统公司投了赞成票，没有发表任何评论。

2003 年 6 月 30 日，IBM 投了反对票，并发表了以下评论： 此 JSR 包含一些有趣的想法。然而，我们对该 JSR 的范围广度和重要方面缺乏明确性感到担忧。特别是，我们认为该 JSR 的范围过于广泛，包括业务服务、数据访问和用户界面绑定等元素。所提议的规范将结合这些方面，从而在业务服务的数据控件的设计和用户界面呈现的需求之间产生不良的耦合。这项工作应分为两个单独的活动，一个定义业务服务和这些服务的数据控件，另一个定义声明性用户界面绑定。这将提高重点，并产生更好地满足这些不同领域需求的规范。除了这个主要问题之外，我们还担心此 JSR 提出的数据控制、声明性绑定的某些方面以及与 JSR 114 和 127 的关系缺乏详细信息。我们正在向 SE/EE 发送电子邮件EC 详细说明了这些担忧。

2003 年 6 月 30 日，BEA Systems 投了反对票，并发表了以下评论： BEA 还对 JSR 227 的范围和分解表示严重关切，因此投了“反对票”。具体来说，我们认为数据控件中体现的功能应该位于与声明性绑定规范不同的 JSR 中，因为数据控件通常可以在规定的数据绑定用例之外使用。因此，在 JSR 中将这些概念耦合在一起是不可取的。此外，由于提议的数据控制架构是各种数据源类型和服务类型的规范化层，因此我们认为这是一个足够复杂的主题，需要独立的 JSR。

2003 年 7 月 2 日，Apple Computer, Inc. 投了赞成票，没有发表任何评论。

2003-07-02 Lea, Doug 投了赞成票，并发表了以下评论： 我相信 IBM 和 BEA 表达的担忧可以在专家组中得到解决。

SAP AG 于 2003 年 7 月 3 日投了赞成票，并发表了以下评论： SAP 认为，该 JSR 通过将单独的 Java 技术绑定在一起并建立可提高生产力的通用设计模式，在简化基于 Java 的业务应用程序的开发方面具有巨大的潜力。声明式绑定的概念将进一步减少编程工作量，使应用程序开发人员更容易专注于解决业务问题而不是系统级细节。尽管如此，我们认为该 JSR 需要在专家组成立后立即进一步确定范围。诸如标准化不同数据源的事务行为或为复杂业务服务定义具体元数据之类的问题，应该在单独的 JSR 中讨论，以保持焦点。此外，为声明性绑定选择有意义的用例将需要与其他 JSR 进行大量协调，并且规范负责人必须确保 J2EE 平台的体系结构完整性。由于其对平台的广泛影响，整体开发工作的透明度至关重要。尽管如此，SAP 认为该 JSR 为 Java 社区提供了良好的机会，也为其他 JSR 提供​​了创新空间，因此对该 JSR 投了“YES”票。

2003 年 7 月 6 日，诺基亚网络公司投了赞成票，并发表了以下评论： 根据 JSR 提案中提供的信息、IBM 和 BEA 提出的问题以及 Oracle 给出的澄清，该 JSR 应继续进行。就范围界定而言，它应作为专家组的首要任务。此外，可以理解的是，JSR 提案本身无法提供该主题讨论中的一些问题所解决的详细程度。因此，IBM 和 BEA 表达的担忧应该在 JSR 的早期阶段、范围界定之后在 EG 中得到解决。此外，不希望 JSR 内的重大技术决策在 EG 的参与下做出。因此，在 EG 讨论并批准之前，详细的技术设计不应被刻在石头上。

2003 年 7 月 7 日，Caldera Systems 投了弃权票，并发表了以下评论： 我们与 SAP 一样担心此 JSR 对 J2EE 体系结构完整性的影响，并且不确定 EG 是否能够成功遵循所有（有些冲突的）指令它是在这个 JSR 上给出的。

2003 年 7 月 7 日，Macromedia, Inc. 投了赞成票，并发表了以下评论： 考虑到这项技术对主流 Web 开发人员的价值以及懒惰地解决该技术的危险，我们必须保持乐观态度，JCP 执行委员会和 JSR 专家集团可以进一步完善此 JSR 的范围，并热切地希望将有关控制和合同细节的辩论转移到专家组，而不会因为否决票而造成延误。

2003 年 7 月 7 日，Progress Software 投了赞成票，没有发表评论。

2003-07-07 惠普投了赞成票，没有发表评论。

2003年7月7日，富士通有限公司投了赞成票，但没有发表任何评论。

2003-07-07 Borland Software Corporation 投了赞成票，没有发表任何评论。

2003 年 7 月 7 日，Apache 软件基金会投了赞成票，没有发表任何评论。