java - 是否打算彻底改造现有的 Java 平台类 (JEP 360)？

Question

Brian Goetz 在 a recent article on InfoQ 中提到使 String final 导致问题:

A good example where we pay for this tension is String; it is critical to the security of the platform that strings be immutable, and therefore String cannot be publicly extensible -- but it would be quite convenient for the implementation to have multiple subtypes. (The cost of working around this is substantial; Compact strings delivered significant footprint and performance improvements by giving special treatment to strings consisting exclusively of Latin-1 characters, but it would have been far easier and cheaper to do this if String were a sealed class instead of a final one.)

他还提到制作一个 final 类 sealed 是向后兼容的:

It is a binary- and source-compatible change to make an existing final class sealed. It is neither binary- nor source-compatible to seal a non-final class for which you do not already control all the implementations.

是否有意回到 Java 平台中的某些 final 类并使它们密封而不是获得性能优势(即，使 String sealed 而不是 final，有一些高性能的实现)？

Answer 1

您要求预测 future ，但听起来有点像您希望有很多类可以从性能调整中受益。此外，如果保证改进，并不是说改进需要密封，只是它可能使事情变得更容易，例如 String 。让 String 密封现在 不如假设它在 10 年前密封时有用。

String 一直是一个非常特殊和重要的案例，因此即使没有密封类，它也被广泛调整(和取消调整):interning , shared char array , compressed and compact strings .这样做总是有很好的动机，因为从任何内存转储中都可以清楚地看到 String(或者更确切地说是它的内部 char[]，在以后的版本中是byte[]) 是应用程序中占用最多内存的部分。

您认为最终类是否真的应该进行调整，或者您只是假设这些类性能不佳？或者您是否希望对代码库进行某种常规清理，这可能会导致非常低的 ROI考虑到您需要进行更改，而性能提升很可能非常小，但您需要进行大量测试。

此外，其他重要的非字符串类也以各种方式进行了调整，你有Integer cache , JVM intrinsics和许多其他事情，因此密封不是主要(甚至次要)的性能工具。