3

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)?

Justin Albano
  • 3,809
  • 2
  • 24
  • 51

1 Answers1

3

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.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • 1
    Thanks for your reply. This was more out of curiosity, since Brian explicitly mentioned one example that would benefit from a sealed implementation. I was curious if there were any plans to rework the existing platform classes using sealed implementations in a similar fashion to how Jigsaw brought with it an overhaul of the package/module structure of the JDK. I.e., an improvement to the language that comes along with (enables) a corresponding improvement to the platform. – Justin Albano Jul 01 '20 at 11:43
  • 1
    @JustinAlbano I understand, but Jigsaw was a major change that affected the whole JDK. Since sealing is backwards compatible, they can freely decide to use it on (final) classes if they deem it useful, but I would expect it to be a design decision rather than something based on performance. There are already plenty of performance tricks in the JVM, so I don't really see this as "hey, now we can improve performance". The String case explains how performance *could have* been improved with a sealed String class *instead* of the tricks I listed above. – Kayaman Jul 01 '20 at 11:54