是否打算对现有的Java平台类(JEP360)进行彻底改造？

Question

Brian Goetz最近在InfoQ上的一篇文章中提到，使stringfinal产生了问题：

我们为这种张力付出代价的一个很好的例子是String；String是不可变的，因此String不能公开扩展，这对于平台的安全性是非常重要的--但是实现具有多个子类型会非常方便。（解决这一问题的成本是相当高的；紧凑的字符串通过对仅由Latin-1字符组成的字符串进行特殊处理，提供了显著的占用空间和性能改进，但是如果String是一个密封类而不是一个final类，那么这样做就会容易得多，成本也会低得多。）

他还提到，使final类sealed向后兼容：

这是一个二进制和源代码兼容的更改，使现有的final类密封。对一个尚未控制所有实现的非final类进行封存，既不兼容二进制，也不兼容源代码。

是否打算回到Java平台中的一些final类，并使它们成为sealed，以获得性能优势（即，使用几个Performation实现，使stringsealed而不是final)？

Answer 1

您要求预测未来，但这听起来有点像您希望有很多类从性能调优中受益。此外，如果需要改进，并不是需要进行密封，而是使用string（例如，string)可以使事情变得更容易。现在密封string就不像10年前密封时那样有用了。

string一直是一种非常特殊和重要的情况，正因为如此，即使在没有密封类的情况下，也对其进行了广泛的调优（或取消调优）：内部、共享字符数组、压缩和紧凑字符串。这样做总是有很好的动机，因为从任何内存转储中都可以很清楚地看出，string（或者更确切地说，它的内部char[]，在以后的版本中是byte[])是应用程序中占用最多内存的东西。

您认为有一个最终的类真的应该调优，还是您只是假设这些类不是Performanct？或者您希望对代码库进行某种形式的一般性清理，这可能会导致非常低的ROI（考虑到您需要进行更改以获得很可能很少的性能改进，但您需要进行大量的测试）。

此外，其他重要的非字符串类也以不同的方式进行了调优，您有了整数缓存、JVM固有特性和许多其他东西，因此密封并不是主要的（甚至是次要的）性能工具。