一厢情愿谬误的建议_敏捷的Java标准-是否一厢情愿？

一厢情愿谬误的建议

上周是JCP执行委员会（EC）每年举行的三场面对面会议之一。 会议结束后，西蒙·里特，副首席技术官Azul系统并在JCP EC候补代表，在写博客文章说一件事已经上了JCP EC的头脑有一段时间是多么的Java SE的标准化将工作在将来。

之前和之后

Ritter在他的帖子中指出，JCP为透明性铺平了道路，标志着“通过标准开发Java平台，API和技术的定义的开放过程的开始”。 在J2SE 1.4之前，Java是内部开发的，Sun在功能和更改方面都做出了决定。

十年前，Sun开源了其JDK的实现，这一决定意味着“ Java社区现在对Java平台的开发有了更大的可视性，并提供了频繁的早期访问版本 。”

迈向更敏捷的Java标准

Ritter认为JDK增强建议（JEP） （用于定义对JDK的更改）“ 是对核心Java SE平台或涵盖的JDK进行更细粒度的更改规范的绝佳方法”，并补充说，该想法是为了使用它们“作为一种更敏捷（因此更现代）的方式向Java交付更改。”

Azul Systems的副CTO解释说，尽管将独立于其他JEP进行开发的各个JEP的事实将使开发人员“在准备好功能后立即利用其功能”，但仍然存在以下问题：这种方法如何起作用在实践中？

使用现有的JSR系统，Java SE的每个主要版本都有一个完整的规范，任何人都可以使用它来创建自己的实现。 还有一个相关的参考实现（OpenJDK）和一个测试套件（TCK / JCK）。 如果我们开始使用细粒度的点发布系统，那么要继续使用JSR，就必须改变JSR的工作方式（Oracle软件开发Java平台小组副总裁George Saab已经表示，目前还没有计划停止使用JSR定义Java SE）。

此外，在主要版本之间引入“较小的功能部件意味着将需要将其规范添加到JSR中以形成汇总。 拥有一个专家组并进行公开评审似乎是使该问题易于管理的权重太大的方法。”

Ritter得出结论，将必须对JCP使用的流程进行一些更改，否则制定敏捷Java标准的想法不太可能实现。

翻译自: https://jaxenter.com/agile-java-standard-wishful-thinking-not-131188.html

一厢情愿谬误的建议