我正在查看JSR 227 page并看到其状态显示为“已撤消”。这个状态意味着什么？这是否意味着它被弃用了？是否有更新版本取代了此规范？
答案 0 :(得分：5)
作为程序员，你没有任何意义。
Oracle为JSF应用程序的用户界面发明了一种声明性方式，以连接到底层数据服务，这是他们的应用程序开发框架（ADF）的核心。由于他们已经构建并在ADF中广泛使用它，并且由于他们将ADF用于他们庞大的新ERP套件（Fusion Applications），因此它将长期存在。
Oracle希望能够说“基于标准”，因此他们以JSR的形式提交了自己的方式。 使用不同方法的IBM认为授予其竞争对手官方JSR没有任何好处，因此他们阻止了它。
它被撤回的事实只是家务管理。
答案 1 :(得分：2)
来自JCP Process document，第2.1节：
在向PMO提出请求后，任何JSR提案可能会在完成JSR批准选票之前由提交者撤回，而无需解释。
所以，这只意味着它在批准之前被撤回，仅此而已。目前还不清楚是否有替代作品。该特定规范简单地表明，它是在规范主管的要求下撤回的。因此，您需要联系Oracle的John Smiljanic以获取详细信息。
阅读JSR Review Ballot comments可能会有所帮助，下面复制完整性。很可能是IBM和BEA提出的问题使甲骨文确信它不值得以现有的形式进行追求，但那是我（我想知情的）推测。
On 2003-06-25 Sun Microsystems，Inc。投票赞成，没有发表评论。
在2003-06-30，甲骨文通过以下评论投赞成票： Oracle理解IBM的问题，但认为可能存在对此JSR细节的误解。这个JSR的范围实际上相当小，并且仅限于能够进行任何绑定并使其可移植到任何标准服务器所需的接口和格式。声明绑定和数据控制的最低要求是此功能。它们各自相互存在。此JSR的范围仅涵盖这些对象的接口，而不是特定的实现。那将是特定于供应商的。甲骨文很乐意澄清这个提案中的任何不明确点，正如我们与其他许多EC成员一样。
在2003-06-27思科系统公司投票赞成，未发表任何评论。
在2003-06-30 IBM通过以下评论投票否决： 这个JSR包含一些有趣的想法。但是，我们担心范围的广度以及该JSR的重要方面缺乏明确性。特别是，我们认为这个JSR的范围太广，包括业务服务，数据访问和用户界面绑定的元素。所提出的规范将组合这些方面，在商业服务的数据控制设计和用户界面呈现的需求之间产生不期望的耦合。这项工作应分为两个单独的活动，一个用于定义这些服务的业务服务和数据控件，另一个用于定义声明性用户界面绑定。这将提高焦点，并将导致更好地满足这些不同领域需求的规范。除了这个主要问题之外，我们还担心这个JSR提出的数据控制缺乏细节，声明性绑定的某些方面以及与JSR 114和127的关系。我们正在向SE / EE发送电子邮件EC详细说明了这些问题。
在2003-06-30 BEA Systems以下列评论投票否决： BEA对JSR 227的范围和因素也有很大的担忧，因此投票＆＃34; No＆＃34;。具体来说，我们认为数据控件中包含的功能应该在声明绑定规范的单独JSR中，因为数据控件通常可以在规定的数据绑定用例之外使用。因此，在JSR中将这些概念结合在一起是不可取的。此外，由于建议的数据控件体系结构是各种数据源类型和服务类型的规范化层，我们认为这是一个足够复杂的主题，需要一个独立的JSR。
在2003-07-02 Apple Computer，Inc。投票赞成，没有发表评论。
在2003-07-02 Lea，Doug投票赞成以下评论： 我对IBM和BEA表达的担忧充满信心 可以在专家组中解决。
在2003-07-03 SAP AG投票赞成以下评论： SAP认为，通过将单独的Java技术绑定在一起并建立可提高生产率的通用设计模式，该JSR具有简化基于Java的业务应用程序开发的良好潜力。 Declarative Bindings的概念将进一步减少编程工作，使应用程序开发人员更容易专注于解决业务问题而不是系统级细节。尽管如此，我们认为专家组一旦成立，就需要进一步确定该JSR的范围。诸如规范化不同数据源的事务行为或定义复杂业务服务的具体元数据之类的问题应该在单独的JSR中讨论，以便保持关注。此外，为Declarative Bindings选择有意义的用例需要与其他JSR进行重要协调，Spec Lead必须确保J2EE平台的架构完整性。由于其对平台的广泛影响，整体开发工作的透明度至关重要。尽管如此，SAP认为这个JSR为Java社区提供了良好的机会，同时也为其他JSR创新提供了空间，因此投票选择了“好”。对于这个JSR。
在2003-07-06诺基亚网络投票赞成以下评论： 根据JSR提案中提供的信息，IBM和BEA提出的问题以及Oracle提供的说明，此JSR应继续进行。作为范围界定的争论，它应该作为EG的首要任务。此外，可以理解的是，JSR提案本身无法提供有关主题讨论中的某些问题已经解决的详细程度。因此，在确定范围之后，IBM和BEA表达的担忧应该在JSR的早期阶段解决。此外，预计JSR中的重要技术决策预先在EG的参与之前是不可取的。因此，详细的技术设计不应该刻在石头上，直到EG讨论和批准它们。
2003-07-07 Caldera Systems以下列评论投票给Abstain： 我们与SAP分享了对此影响的担忧 JSR关于J2EE的架构完整性，以及 不确定EG是否可以成功 遵循所有（有点冲突的）指令，它在这个JSR上给出。
On 2003-07-07 Macromedia，Inc。投票赞成以下评论： 考虑到这项技术对主流Web开发人员的价值以及用懒惰解决它的危险，我们必须乐观地认为JCP执行委员会和JSR专家组可以在未来改进JSR的范围，并且热情地希望改变关于控制和合同细节的争论进入专家组，没有任何投票会导致延迟。
在2003-07-07进步软件投票是，没有评论。
2003-07-07 Hewlett-Packard投票赞成没有发表评论。
在2003-07-07富士通有限公司投票赞成，没有发表评论。
2003-07-07 Borland Software Corporation投票赞成，未发表任何评论。
在2003-07-07，Apache Software Foundation投票赞成，没有评论。