Brian Goetz mentioned in a recent article on InfoQ that making String
final
caused problems:
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.)
He also mentions that making a final
class sealed
is backward-compatible:
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.
Is there any intention to go back to some of these final
classes in the Java platform and make them sealed
instead to gain performance benefits (i.e., making String
sealed
instead of final
, with a few performant implementations)?
You're asking to predict the future, but also it sounds a bit like you expect there to be a lot of classes that would benefit from performance tuning. In addition it's not that sealing is required for improvement if improvement is warranted, it's just that it might have made things easier with String
for example. Making String
sealed now isn't as useful as it would've been if it had been sealed let's say 10 years ago.
String
has always been a very special and important case, and because of that it has been extensively tuned (and de-tuned) even without sealed classes: interning, shared char array, compressed and compact strings. There has always been a very good incentive to do this, as it's very clear from any memory dump that String
(or rather its internal char[]
, which in later versions is a byte[]
) is what takes most memory in applications.
Do you think there's a final class that should really be tuned, or are you just assuming that the classes are not performant? Or are you hoping for some sort of general cleanup of the codebase, which would probably result in a very low ROI considering you'd need to make the changes for most likely very little performance improvement, but you would need to do a lot of testing.
In addition, other important non-String classes have been tuned in various ways as well, you've got Integer cache, JVM intrinsics and many other things, so sealing is not primarily (or even secondarily) a performance tool.