随着Java社区对Java模块系统的投票即将结束，Oracle的一位高级官员在红帽的批评中再次为该计划辩护。
模块化是Java 9中的主要特性，预计7月27日抵达对模块化的分歧并不会阻碍发布。甲骨文公司Java平台部门的首席架构师Mark Reinhold周一在openjdk邮件列表中发送了一封电子邮件，称被提及的问题已经得到了解决。
“从那时起，我已经看到了没有新的信息怂恿我改变他们自己的看法，”莱因霍尔德说。在回答Red Hat的大卫·劳埃德后，莱因霍尔德说，每一个变化对现有功能的兼容性承担风险。劳埃德说Red Hat和其他Java执行委员会成员已经在说明书传达的“种种不足”。但莱因霍尔德说，每次加入放在如何该平台能够在未来发展的硬约束。“这一些是什么必须是更广泛和长期后果进行透彻的分析仅仅是开始发生变化或添加出现有用，”莱因霍尔德说。“这改变或添加是‘很容易’实现是完全不相干的。”
劳埃德的批评紧随其后批判的模块化平台他说，这一添加可能会导致应用程序兼容性问题，并让开发人员需要处理两个领域，一个是模块化的，另一个不是。然而，莱茵霍尔德呼吁“负责任的管理”，并表示社区必须拒绝任何仅仅对某些人有用的建议。“如果不这样做，将是极其不负责任的。”
Lloyd要求在运行时在模块之间存在周期。Reinhold回答说，Java Specification Request (JSR)的主要目标是创建一个所有开发人员都可以使用的模块系统，而不仅仅是应用服务器开发人员。(红帽销售JBoss Java应用服务器。)“这种想法的一个结果是，这个模块系统强加了一些约束，旨在使工作系统更容易推理和指导开发人员更好的实践，”Reinhold说，并补充说，在未来的版本中可能会添加循环。
Reinhold还反对红帽提出的原语，说它们限制了模块系统的未来发展。设计一组这样的原语，也就是。，一个‘元’模块系统，不是这个JSR的目标，”他说。
红帽的Lloyd还建议在模块路径模块之间隔离包名称空间，但是Reinhold说开发人员通过对包名称使用反向dns约定来改善这个问题。“如果一个应用程序现在在类路径上正常工作，那么它可能一开始就没有冲突的包，因为类路径上冲突的包经常会导致麻烦。”The module system places application modules into a single class loader by default, so developers have one fewer behavioral difference to deal with when upgrading components to explicit modules.
投票在JSR 376是缔结周一，但结果可能直到晚6月公布。上个星期，Reinhold指控IBM和红帽公司反对模块系统是出于自身利益。劳埃德，不过，建议莱因霍尔德不承担Red Hat或在许多问题上已经投降后，别人会投反对票了只有自身利益的。“我们正在寻找到推动这个在我们的最低线，也可以解决其他EG（专家组）和欧盟成员共同关注的关键的几个关键问题的切实可行的解决方案。”
这个故事，“Oracle回击模块化Java批评家”，最初由信息世界 。