当JVM最初被绘制时，设计者在常量池中使用CONSTANT_Long_info和CONSTANT_Double_info结构占用2个条目（据说这样，你可以通过4字节对齐或沿着这些行的某些东西索引常量池）。
但是，根据JVM 10 specification, that has not been changed。
如果更改它需要更改大量代码，那么它是有意义的，因为JVM应该能够运行为旧JVM构建的代码，但在我看来，它需要很少的更改，条件确定你是否“处理来自早期版本的类 - 唯一相关的是，如果你正在初始化常量池，或者你正在迭代它，这种情况不会经常发生，并且无论如何都充满了条件。
此外，过去已经引入了更大的突破性变化，例如Java 9模块。那么，为什么今天仍然如此呢？是否有建筑理由，或者到目前为止它是否值得任何人的时间？
与从Java 1.1到Java 11的大多数更改一样，在字节码格式方面，模块的引入并没有太大变化。当涉及到应用程序逻辑或反射时，它可能是激进的，而不是字节代码处理工具，它只需要轻微的扩展。
改变CONSTANT_Long_info和CONSTANT_Double_info的逻辑只有在你寻求更大的图景时才有意义，例如：还改变了long和double采用两个局部变量和两个操作数堆栈条目的事实。然后，你将不得不触摸安静很多代码的地方。
但无论变化有多大或多大，重要的问题是，你获得了什么？更好的感觉不算数。改变它的主要原因是简化规则，因此，字节码处理工具。但是，由于这些工具需要条件来启用仍然存在的旧类文件的处理，因此这种优势不会实现。实际上，随着这种变化，这些工具将变得更加复杂。
当你开发一种全新的格式时，它会有所不同，这种格式需要新的工具，例如：它本来是JMOD格式的一个选项，但是开发新工具链的必要性是它没有发生的原因，而且当前的JMOD只是一个像旧jar文件一样的zip文件。
一个反例是the StackMapTable attribute，它在开发时没有向后兼容性约束，因此，不计算两次long和double条目。处理工具的职责是将这些stackmap条目转换为堆栈框架条目，这些条目对long和double值使用两个（除非我们讨论的是反过来进行转换的环境）。