jcp jsr_JCP执行委员会未能支持社交媒体API

jcp jsr

投票已经进行表决并得到核实，并且JCP现在可以显示，在审核投票阶段尚未批准针对Java SE和Java EE的拟议社交媒体API 。

赞成Java规范的评审团在3月初就 Werner Keil提出的Social Media API的优劣做出的决定中，分歧很大。

尽管许多人意识到更新社交媒体的必要性，但许多人对这项任务的范围表示担忧，并说不可能将所有这些都适合于更广泛的Java社区所采用的可行规范。

在社交媒体API上，IBM无疑是最挑衅的，他指出：

目前，社交媒体编程模型周围的环境的特点是，开放标准社区（如OpenSocial Foundation）和开源社区（如Apache Shindig，Abdera2和Rave）的发展非常Swift。 JSR 357会尝试将总体API结构放在这些活动部件的集合上。

IBM认为，在社交媒体环境的生命周期中，将JSR 357 Java API推向市场还为时过早，这充其量只会造成混乱，并有可能阻碍当前正在广泛开展的工作的发展。

这是一种公平的批评–社交媒体的流量如此之大，以至于在实施规范时，它在某些方面可能是无效的。 但是Keil确实在最初的规范中说过，这些社区并不像以前那样活跃，他们也不愿意接受日新月异的领域。

IBM走得更远，提供了另一种方法：

IBM认为正确的方法是允许市场围绕不断发展的社交媒体模型进行整合，并随着它们的成熟提供强大的Java API绑定，从而为Java社区提供对社交应用程序有用的“入门”，从而为我们的客户提供价值。 当时机成熟，并且Java社区对我们的客户对Social Media API的理解更加成熟时，IBM希望采用一组更具体的JSR提案，每个提案都针对Social Media API中特定领域的客户需求。看到发展。

其他人也表达了他们的观点，包括伦敦Java社区，该社区表示尽管有意修改已失效方法的天性，但仍存在“重大缺陷”，并且希望将其分解为较小的JSR。

其他对JSR 357投票反对的人包括Azul Systems，Eclipse Foundation，爱立信AB，谷歌，惠普和SAP。 但是，有些人投了赞成票，看到了JSR的优点，并希望推动社交媒体标准化。

瑞士信贷表示以下意见：

我们有兴趣融合各种行业标准（Open Social和其他行业标准），并从JCP推动社交网络技术的标准化。 我们关注两点：请求中提到的广泛范围和安全性。 因此，我们建议必须对API功能的安全性进行清楚的调查，并且必须给出安全使用和实现API的适当指南。

JCP执行委员会成员和社交媒体巨Twitter Twitter对此辩论颇有兴趣，他们投了弃权票，但他们确实表示，他们认为“现在就开始标准化社交活动还为时过早，并鼓励人们寻求第三方图书馆的支持，以与众多图书馆建立联系。社交网络。”

反思一下，由于媒体的性质不断变化，这似乎是正确的决定。 Java确实在将来的某个时刻需要对社交媒体进行全面检查，但是由于我们对社交网络的了解仍然充斥着所有复杂性，因此最好让第三方先对其进行处理，而不要介入金本位制和犯错。 。

翻译自: https://jaxenter.com/jcp-executive-committee-fail-to-back-social-media-api-104290.html

jcp jsr