Oracle的Java首席设计师MarkReinhold最近宣布了关于JDK18.3的提议计划。这个计划与JDK8带有同样的里程碑式的意义，虽然功能还尚未完善。
MarkReinhold在与OpenJDK邮件表中宣布，JDK18.3的拟议日程表如下：
/12/14第一阶段
/01/11运行所有测试
/01/18第二阶段
/02/22发布最终候选人
/03/20一般可用性
在这为期六个月的JDK18.3版本中，每个功能必须在集成之前完成。实际上，JDK18.3的主开发线始终是完整的。版本中的功能集也包含第一阶段之前集成的功能。
Reinhold补充道，他很快就会制定出一个详细的功能计划，JDK18.3的功能至少包括所有必需的代码、规范文本和单元测试。”
如果在10月18日之前无反对意见或者已经获得满意的回答，该提案将被采纳为JDK18.3的议程。
SAP的VolkerSimonis提出这是否意味着JDK18.3存储库会在第一个阶段进行之前创建的疑问，并对JDK18.3之后的工作模式产生了兴趣。
“JDK18.3版本之后的工作模式是怎样的?是先进行bug修复去JDK-dev，转到JDK18.3，还是直接插入JDK18.3?如果是后者，JDK18.3的修复程序是否会自动整合到JDK-dev中?”
关于编号方案:旧方案还有希望吗?
新旧编号方案的话题也在JAX伦敦小组与Oracle的DonaldSmith,DanielBryant,StephenColebourne,PeterLawrey和MartijnVerburg的讨论中出现了。
关于新的编号计划产生了一个有趣的想法---StephenColebourne表示对这一提议不满意，由于他最近写了一个关于10，11，12等Java版本号的请求，所以这并不令人意外。
他认为，尽管LTS版本对Oracle和其他大企业都很重要，但对社区来说并没有那么重要。
Colebourne还建议，LTS版本应该逐渐增加，比如
/p>
年3月——v10
年9月——v11
年3月——v12
年9月——v13
