Brian Goetz 在最近一篇关于 InfoQ 的文章中提到 make会String final导致问题：
我们为这种紧张付出代价的一个很好的例子是 String；字符串不可变对平台的安全性至关重要，因此 String 不能公开扩展——但如果实现具有多个子类型会非常方便。（解决此问题的成本很高；紧凑字符串通过对仅由 Latin-1 字符组成的字符串进行特殊处理，显着提高了占用空间和性能，但如果 String 是一个密封类，这样做会更容易也更便宜而不是最后一个。）
他还提到创建一个final类sealed是向后兼容的：
这是一个二进制和源代码兼容的更改，以使现有的最终类密封。密封您尚未控制所有实现的非最终类既不兼容二进制也不兼容源。
有没有打算回到finalJava 平台中的这些类中，并改为使用它们sealed来获得性能优势（即，使用一些高性能实现String sealed来代替）？final
您要求预测未来，但这听起来有点像您期望有很多类将从性能调整中受益。此外，如果需要改进，则不需要密封来改进，只是它可能使事情变得更容易，String例如。现在进行String密封并不像 10 年前密封那样有用。
String一直是一个非常特殊和重要的案例，因此即使没有密封类，它也已被广泛调整（和取消调整）：实习，共享字符数组，压缩和紧凑字符串。这样做总是有很好的动机，因为从任何内存转储中都非常清楚String（或者更确切地说，它的 internal char[]，在以后的版本中是 a byte[]）是应用程序中占用大部分内存的原因。
您是否认为应该真正调整最终类，或者您只是假设这些类没有性能？或者您是否希望对代码库进行某种一般性清理，考虑到您需要进行更改以获得极小的性能改进，这可能会导致非常低的投资回报率，但您需要进行大量测试.
此外，其他重要的非字符串类也以各种方式进行了调整，你有整数缓存、JVM 内在函数和许多其他东西，所以密封不是主要（甚至次要）性能工具。