jcp jsr
当JCP以8票对5票否决JSR 357 （社交媒体API）时，成员们批评它的范围太广，没有充分考虑安全性和移动空间。 但是，赞成该建议的成员表示这是政治举措，并阻碍了创新。 “我自2008年以来一直在执行委员会（EC）工作，自2005年以来一直担任JCP和专家组（EG）成员，因此，尤其是在EC中，我不断观察到这些问题和原因，我不只是认为还是推断”，规范负责人Werner Keil告诉InfoQ。 “作为ME EC成员的我的前任之一Jean-Marie Dautelle有理由不再竞选EC职位，类似于Sean Sheedy，这些原因都与这样的决策更具政治性或法律性，技术性或逻辑性较低被制造。”
对于标准Java Java社交API的需求已经讨论了一段时间。 早在2010年10月在波恩举行的执行委员会面对面会议上，Oracle一直在争论 Java ME应该包含一个社交网络接口，从而允许
...应用程序和本地Web服务（servlet），以与OpenSocial等接口并托管第三方社交应用程序（例如hi5，LinkedIn，MySpace，Netlog，Ning，orkut，XING，Yahoo！...）。
但是，JSR 357很难获得很多支持。 在执行委员会的16名成员中，只有五名（瑞士信贷，高盛，红帽，Oracle和SouJava）投票赞成该提案。 八名成员投票反对（Azul Systems，Eclipse Foundation，爱立信，谷歌，惠普，IBM，伦敦Java社区和SAP），而富士通和Twitter弃权而英特尔未投票。 总的来说，即使是那些投赞成票的人，也批评JSR的范围太广。
由于瑞士信贷在执行委员会中代表客户的观点，因此我们有兴趣整合各种行业标准（Open Social和其他行业标准），并希望通过JCP推动社交网络技术的标准化。 我们关注两点：请求中提到的广泛范围和安全性。 因此，我们建议必须明确研究API功能的安全隐患，并且必须给出安全使用和实现API的适当指南。
弃权的Twitter和其他人也指出，尝试标准可能为时过早。
虽然我们最初对该提案感到兴奋，但我们认为现在开始标准化社交还为时过早，并鼓励人们寻求第三方图书馆的支持以连接到众多可用的社交网络。
在否决票中，伦敦Java社区（LJC）评论
LJC赞扬在社交媒体领域建立共识的努力，但我们认为该建议存在重大缺陷，因此，我们目前无法支持。
我们看到的关键问题是API包含高度的领域建模，该领域的建模过于僵化而无法轻松容纳不断发展的空间。 缺乏对移动的关注也是一个重大缺陷-2012年，社交媒体越来越受到移动应用程序的驱动-拥有不与ME标准流程协调的社交JSR毫无意义。 LJC欢迎撤回该提议，并欢迎其以较小的JSR代替，而JSR则针对此空间的特定部分。
InfoQ与执行委员会伦敦Java社区的代表Ben Evans进行了交谈，他还对提案没有充分强调移动性表示担忧。
在红木海岸的一月面对面会议上讨论了该提案。 有关该提案的反馈很多，包括EC成员在对JSR 357的评论中提出的许多具体批评的形式。LJC的感觉是，EC会议的反馈并未并入草案中。最终提交了考虑-这对于JSR的整体发展而言是不利的。 特别是，JSR 357是作为SE / EE规范提交的，没有真正强调移动性。 尽管平台融合正在发生，但距离还有很长的路要走，社交是与移动有很大关系的空间。
凯尔（Keil）向InfoQ建议，IBM在此过程的早期阶段决定不投票的决定可能已经影响了其他人，并且鉴于IBM最近已向Facebook出售了750项专利（至少根据彭博社报道） ，这可能具有政治议程。 他的副总裁安托万·萨博特·杜兰德（Antoine Sabot-Durand）还是红帽公司的Seam Social的负责人 ，却没有分享这一分析。 他告诉InfoQ：“我认为JSR被否决有四个原因。”
1）新的JSR类型
到目前为止，大多数JSR都在处理开发的技术方面（可共享组件，ORM，事务，Web服务），而我们的JSR是最早（包括JSR 351 ）处理高层问题并使用横向技术（JAX）的公司之一-RS 2.0，JSONP，CDI，JSR 351等）。 由于它不在JCP文化中，因此我们必须更加精确，并在教学法上进行更多的工作。
Sabot-Durand和Keil都指出，尽管社交供应商的空间仍然非常活跃，但是Social Media API并不是没有真空的。 除了前面提到的基于CDI的Seam Social之外，还有DaliCore和Apache Rave ，后者与Sun自己的（现在已停产） SocialSite共享很多方面， Apache Rave最近成为了一个顶级项目，尽管它依赖于Wookie。 ，其本身仍在孵化中。 其他产品和API包括eXo Social ，VMware的Spring Social和Twitter4J （用于Twitter API的非官方Java库）。 尽管如此，到目前为止，还没有一种常见或占主导地位的方法的感觉，并且JSR规范几乎肯定需要具有相当的创造力。 有鉴于此，拒绝JSR的决定重新引发了关于JCP是否可以并且应该用于促进创新的争论。
最近加入JCP的Azul Systems是拒绝该提议的组织之一。 InfoQ向他们的JCP代表和CTO Gil Tene谈到了他的推理。
InfoQ ：您如何看待JCP内部以及通过JSR进行创新和推动新标准？
我认为JCP应该在其控制和范围内的领域进行创新，并为此可以召集可信赖的专家组，在相关主题方面引领行业。 我还认为，JCP不应尝试在这些界限之外进行创新。 我认为富有成效的JSR工作可分为三大类：
b）采用并与外部主导的非平台特定标准进行交互，并遵循既定的行业创新。 例如XML，HTTP，SCTP，JSON，OSGi等。
c）在存在真空的领域进行创新，在Java平台提供了一个构建整个行业尚不可用的新功能的好地方，在JCP可以让可靠的领域专家和行业领导者定义有用的标准的领域机构自然不会尝试在特定于平台的环境之外进行标准化。 例如Java EE和新的容器类型。
在上面的第一和第三类中，有很多工作要做的空间。 在我看来，让JCP尝试标准化远远超出Java平台并且处于不断变化状态的事物，这从根本上是错误的，并且最终会以没有人使用的标准告终。 当行业已经在努力稳定，建模和标准化行为时，JCP的作用显然是跟随而不是领导。 想象一下，在W3G决定标准是什么样之前，JCP试图在“不断变化”时对XML进行标准化。 或者尝试在IETF草案似乎稳定之前对SCTP进行标准化。
InfoQ ：您认为社交媒体不值得使用Java API吗？
看到Java的社交媒体API，我们将感到非常兴奋，但这显然属于我之前提到的第二类JSR。 我认为，只有在尘埃落定于其他机构和社区正在积极开展的工作之后，并且似乎就社交媒体API的初始版本（未明确捆绑在一起）达成某种稳定的协议之后，才应将此类API部分标准化。或仅限于Java平台）进行建模和包含。 例如，实际上不与Facebook，Twitter，Google +和LinkedIn等社交媒体进行交互并成功建模的标准化Java社交媒体API将变得“愚蠢”，并且将很快过时。
对于整个行业来说，通用模型和支持此类交互的API的发展仍处于领先地位。 我认为，JCP不是领导这种行业范围内努力的合适场所。 当它似乎正在走向成功之路时，它是一个遵循的正确地方。 我确实认为社交媒体互动的某些狭窄方面已经得到很好的理解，并且已经形成了稳定的共同点。 我将支持一个JSR，该JSR专注于遵循这种外部领导的努力，并建立Java平台语法和与之交互的方法。
我认为这不是JSR 357提出的。 它的目标，可感知的需求和拟议的范围似乎远远超出了与现有媒体进行交互并使用已建立的界面的范围。 您可以在http://jcp.org/en/jsr/detail?id=357上阅读规格说明并自行判断。
我认为，这表明，目前在该领域中与行业问题最相关的两个JCP EC成员（Twitter和Google）都没有投票支持上述JSR提案。 没有这些参与者的支持，标准化的尝试将从一开始就注定要失败。 我希望将来能看到这些成员和其他行业利益相关者可以支持的JSR提案。
InfoQ ：您认为此类API的标准化是否可以或应该禁止潜在的专有实现和供应商锁定？
我最关心的JSR 357拟议范围的问题之一； 它对以下问题的回答：“为什么现有规范无法满足这种需求？” 具体说来就是：“……但是，尽管其中大多数都是基于准标准或专有技术构建的，但即使API本身可以免费或开源提供，也增加了厂商锁定的风险……”。
虽然我坚决支持开放源代码并主张启用非专有标准实现，但我认为让JCP强制实施开放源代码实现比禁止它们更有意义。 标准的作用是允许多个相互竞争的实现保持兼容性并可靠地进行交互。 这包括专有的，封闭的，昂贵的和严格许可的实现，以及各种开放开发，免费和/或开源许可的实现。 我不希望看到任何一种实施模型都被标准机构禁止。
至于供应商锁定，这是各种技术的用户最终决定的事情。 我当然更喜欢这样的世界：存在多个选择，并且它们之间具有轻松的移动性，但这不是您可以有效地强制采用标准的事情。 就其本质而言，标准建议启用多个实现，因此是一种选择。 存在多种选择时，肯定会发展出一个健康，充满活力的生态系统。 但是，当至少在一段时间内，一个共同的，单一的选择如此容易和自由地获得以至于人们不再关心选择并接受“相同”时，它也会演变。 这种事情通常会持续到下一次中断，或者直到容易获得的单项选择以某种方式落在后面，促使我们再次选择真正的“选择”。
JCP主席帕特里克·柯伦（Patrick Curran）不想评论此特定JSR的相对优点，但对标准机构应该或不应该创新的事物表达了类似的看法。
在标准组织内部进行创新通常不是一个好主意，因为定义后的标准需要保持稳定。 换句话说，您需要在第一时间解决问题。 如果您尝试在技术日新月异的领域进行标准化，或者对应该采取的技术方法缺乏普遍共识，那么您不太可能在第一时间就把它弄对，或者要么主要-可能是不兼容的-将来会发生变化，否则可能会随着行业的发展而忽略您的标准。
比较安全的方法是在标准化过程之外进行创新，直到达成广泛共识，并且至少一种（最好是一种以上）实施被广泛使用。 此时的标准化工作更有可能成功。
正如Sabot-Durand先前指出的，这种方法导致将许多成功的API引入Java，例如CDI和JPA。 而且，现在OpenJDK已成为Java本身的参考实现，这越来越成为Java语言创新的完成方式。
Sabot-Durand提出了一个相关的观点，即标准机构内部的创新通常会导致失败。
JCP是标准化组织，而不是研发实验室。 我不认为它的作用是推动创新，而要验证它。 长期以来，JCP尝试通过在实施重要规范之前创建重要的规范来进行创新。 EJB 1.X和2.X是由JCP驱动的这种“创新”的示例：失败。
在2002/2003年左右，JCP改变了其政策，现在更愿意从开源世界中获取创新并将其标准化。
标准化可能成为创新的障碍。 这是JCP的主要责备人员级别：“如果我从Java EE开始我的项目，那么我将被这批技术等待4年，等待JCP交付下一个Java EE版本。”
在那里，像CDI这样的规范发挥了作用：它允许开发人员为该标准创建技术和功能可移植的扩展，并允许他们在Java EE版本之间进行演进。 它是扩展标准并将创新引入JCP的引擎。 这是我加入Seam 3团队以及现在加入Apache DeltaSpike项目的主要原因。 大多数Java创新将在这里诞生。
正如Curran所言，另一种选择是在第一时间做到正确，但这在实践中很少发生。 例如，考虑使用Joda-Time ，它是Java的日期API的一种广泛使用和流行的替代品，但是它的作者Stephen Colebourne声称它“ 具有设计缺陷 ”-因此，新的Java日期和时间API（ JSR 310 ）不只是Joda-Time作为JSR。
并非所有人都同意。 专家组提名人Markus Eisele在他的博客中写道， 他是味精系统的首席技术顾问，他的看法与众不同。
我自己不确定这是否是一般而言与JCP一起使用的正确方法。 如果仅采用已经存在的常识是常识，那么JCP将比过去更快地落后于最新的发展和趋势。 而且它总是会遵循某种记录现状的方法。
InfoQ与Eisele进行了交谈，以进一步了解他的想法。 尽管他接受的事情并不像他的博客文章所暗示的那样黑白两分，但他的确提出了JCP应该更多地努力支持创新。
让我再退一步，看看整个行业的标准化。 您可以找到有关特定标准主体（ANSI，ISO等）的历史的一些有趣的文章（ 一 ， 二， 三 ）。 它们都有一个共同的主题：标准化是技术知识的协同生产和传播。
此外，DIN EN 45020将术语“标准”定义为“通过共识建立并得到公认机构批准的文件，该文件旨在为活动及其结果提供通用，重复使用的规则，准则或特性，以用于在给定背景下实现最佳秩序度”。
这里的对立面是您需要自由的空间来进行创新，而标准化通常旨在融合并提供有效的过程和工具。 有人可能会认为，建立适当的标准是该特定领域创新的终结。 再看帕特里克的评论，您可能会觉得过去完全不需要创新。
让我们回过头来看看“利益相关者”。 人们开发和使用标准呢？ 与其他标准机构相比，JCP与此一致。 提议的标准可以由任何JCP成员提交，并且一旦被接受，标准化项目就负责使相关和感兴趣的各方参与。 这里的主要区别在于，大多数官方标准化组织的目标都是拥有更广泛的利益相关者基础。 现在，从JCP EC来看，您主要看到两类-供应商和消费者。 回顾“合作”和“传播”两个词，这似乎是一个很大的缺点。 研究，大学，政府，独立专家呢？ 而且，我还讲了关于道格·利阿（Doug Lea）离开JCP的古老故事 。 让我在这里引用他：
“我相信，JCP不再是一个可靠的规范和标准机构，Sun最初在JSPA和流程文档中放置了足够的规则，以确保JCP可以促进创新。但是，其中一些规则以及违反规则的行为被发现是僵局和失去技术基础的根源。”
听起来很熟悉，对吧？ 即使他拒绝完整的JCP，我也只是批评其中的一部分。 让我非常清楚地说明这一点：JCP通常是我的工作标准机构。 从组织的角度来看，事实是，鉴于执行委员会目前的组合，几乎没有机会进行真正的技术创新。 为此，我们缺少合适的利益相关者。 我认为，只要能从自己的专有解决方案中赚到足够的钱，EC上的任何供应商都不会对“通用和重复使用”准则达成一致。 老实说，没有人对此负责。 即使在我个人这样舒适的情况下，我的行为也可能不会有太大不同。
鉴于此，我坚信JCP必须找到一种以正确的方式再次处理创新的方法。 不仅可以巩固过去所做的工作。 JCP涵盖了整个语言生态系统的特征，因此必须积极推动创新。 我可以想象有两种方法可以促进这一点。 一个简单的想法就是简单地增加EC的多样性。 JUG加入JCP并在EC上使用SouJava已经开始了这一运动，但我们在这里还没有一个健康的组合。 鉴于JCP的所有工作都是自愿性质的，因此许多个人，甚至是研发人员也要克服这一障碍。 需要找到一种方法来消除这一障碍。 另一个想法可能是将流程分为职责不同的不同EC（或具有支持委员会）。 一个可以是技术委员会，而另一个可以处理政治问题。
所有这些或多或少是我自己的头脑风暴，直到今天仍未考虑。 我可能不是在这里提出新结构的合适人选。 但是我喜欢推动Oracle提出更多的想法。
正如我们先前所讨论的 ，Oracle当然已经在努力改革JCP。 JSR 348开始了该过程，而JSR 355则希望合并两个JCP执行委员会。 除此之外，第三份JSR计划研究围绕IP和许可权的复杂问题，这是Sun Microsystems与Apache Software Foundation之间争执的核心，最终导致Apache离开JCP。
尽管Keil和Sabot-Durand可以根据JCP的规则在14天内重新提交计划，但他们告诉InfoQ他们不会这样做。 相反，它们将延迟到JSR 355合并两个执行委员会。 凯尔告诉我们
由JSR 355改革发起的合并后的EC看起来会略有不同。 虽然某些规则（例如，您对JSR的最低“赞成”票数）是相同的，但是只有一个“池”投票数，他们必须为决定寻求一个多数票； 不是两个。 目前，这几乎就像美国参议院和众议院一样，美国政治不断向我们展示这两个通常如何“有效”地协同工作，尤其是当它们各自由不同政党或意识形态主导时。
因此，我们对Mobile的重视程度越高，跳过14天再尝试一次（可能在7到14个月之间）就越有意义。
值得注意的是，拒绝此JSR的决定还有其他一些含义。 eXo告诉我们
如果该JSR被接受，则eXo计划作为商业会员加入JCP，以参加JSR 357（Alain De France将代表该XSR的eXo）。 如果就该主题提出并接受了其他建议，则eXo将加入JCP积极开展工作。
最后，尽管这种延迟可能对双方都有利。 在进行另一次标准化尝试之前，应该给Seam Social和其他人更多的时间来研究开源项目中的问题，这反过来可能会导致更好的标准。 正如本·埃文斯（Ben Evans）在谈话中告诉我们的那样，
我们很高兴看到Antoine Sabot-Durand在这个领域成功运行了F / OSS项目，以期在他获得蓬勃发展的项目后运行较小的JSR。
jcp jsr
3508
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
