是否打算对现有 Java 平台 类 (JEP 360) 进行大修？
Any intention of overhauling existing Java platform classes (JEP 360)?
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 class 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 classes 并使它们 sealed 而不是获得性能优势（即, 使 String sealed 而不是 final, 有一些高性能的实现)?
您要求预测未来，但听起来有点像您希望有很多 class 会 从性能中受益调整。此外，如果需要改进，并不是说密封是改进所必需的，只是它可能会让事情变得更容易，例如 String。使 String 密封 现在 不如假设它在 10 年前密封时那么有用。
String 一直是一个非常特殊和重要的案例，因此即使没有密封 classes：interning, , compressed and compact strings 也被广泛调整（和取消调整） .这样做总是有很好的动机，因为从任何内存转储中都可以清楚地看到 String（或者更确切地说是它的内部 char[]，在以后的版本中是 byte[]）什么在应用程序中占用最多内存。
您是否认为最终的 class 确实应该进行调整，或者您只是假设 classes 性能不佳？或者您是否希望对代码库进行某种全面的清理，这可能会导致非常低的 ROI 考虑到您需要进行更改以获得很可能非常小的性能改进，但您需要做大量 测试。
此外，其他重要的非字符串 classes 也以各种方式进行了调整，你有 Integer cache, JVM intrinsics 和许多其他东西，所以密封不是主要的（甚至其次）性能工具。
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 class 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 classes 并使它们 sealed 而不是获得性能优势（即, 使 String sealed 而不是 final, 有一些高性能的实现)?
您要求预测未来，但听起来有点像您希望有很多 class 会 从性能中受益调整。此外，如果需要改进，并不是说密封是改进所必需的，只是它可能会让事情变得更容易，例如 String。使 String 密封 现在 不如假设它在 10 年前密封时那么有用。
String 一直是一个非常特殊和重要的案例，因此即使没有密封 classes：interning, String（或者更确切地说是它的内部 char[]，在以后的版本中是 byte[]）什么在应用程序中占用最多内存。
您是否认为最终的 class 确实应该进行调整，或者您只是假设 classes 性能不佳？或者您是否希望对代码库进行某种全面的清理，这可能会导致非常低的 ROI 考虑到您需要进行更改以获得很可能非常小的性能改进，但您需要做大量 测试。
此外，其他重要的非字符串 classes 也以各种方式进行了调整，你有 Integer cache, JVM intrinsics 和许多其他东西，所以密封不是主要的（甚至其次）性能工具。