5

我正在检查JSR 227 页面，看到它的状态显示为“撤回”。这个状态是什么意思？这是否意味着它已被弃用？是否有更新的版本取代了这个规范？

4

2 回答 2

5

对于作为程序员的你来说，这并不意味着什么。

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

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

它被撤回的事实只是家务。

于 2013-07-10T13:00:48.420 回答
2

从JCP 流程文档，第 2.1 节：

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

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

阅读JSR Review Ballot 评论可能会有所帮助，为了完整起见，复制如下。IBM 和 BEA 提出的担忧很可能使甲骨文相信，以目前的形式不值得追求，但那是（我想是有根据的）我的猜测。

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

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

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

在 2003 年 6 月 30 日，IBM 投了反对票，并发表了以下评论：这个 JSR 包含一些有趣的想法。但是，我们担心范围的广度以及此 JSR 的重要方面缺乏明确性。特别是，我们认为这个 JSR 范围太广，包括业务服务、数据访问和用户界面绑定的元素。提议的规范将结合这些方面，在业务服务的数据控制设计和用户界面呈现的需求之间产生不合需要的耦合。这项工作应该分为两个独立的活动，一个定义业务服务和这些服务的数据控件，另一个定义声明性用户界面绑定。这将导致重点提高，并导致规范更好地满足这些不同领域的需求。

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

2003-07-02 Apple Computer, Inc. 投了赞成票，没有发表评论。

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

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

2003 年 7 月 6 日，Nokia Networks 投了赞成票，并发表了以下评论：根据有关 JSR 提案的可用信息、IBM 和 BEA 提出的问题以及 Oracle 的澄清，该 JSR 应继续进行。就范围界定而言，它应该作为 EG 的首要任务。此外，JSR 提案本身无法提供有关主题讨论中的一些关注点已经解决的详细程度，这是完全可以理解的。因此，IBM 和 BEA 所表达的担忧应该在 JSR 的早期阶段，在确定范围之后在 EG 中得到解决。此外，不希望在 EG 之前就已经在 J​​SR 中做出重大技术决策。因此，在 EG 讨论和批准之前，不应将详细的技术设计刻板印象。

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

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

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

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

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

在 2003 年 7 月 7 日，Borland 软件公司投了赞成票，没有发表评论。

2003-07-07 Apache 软件基金会投票赞成，没有任何评论。

于 2013-05-14T06:36:21.187 回答