OK, though I think "happen to know" and "is firmly specified to be" are somewhat different things. The former seems depending on a happy accident of implementation, whereas the latter is a semantic guarantee of the class.
Comments
Log in with your Bluesky account to leave a comment
"Happen to know it is firmly specified to be." :-)
I push on this because the reader of the client-side code does not necessarily have the mental database of which types this is safe for. Each javadoc lookup is a readability point deduction.
Any class can be written to control its instances. Enums do so automatically, as do properly-written singleton classes. But there's nothing magic about these examples; you just have to write it correctly. (In the JDK, MethodType is a counterexample to your claim.)
While that's true, I doubt it would be the right idea very often. Most non-enum classes that might be inclined to do that should just become value classes, and let the VM handle everything. Class feels like a relatively special example.
(I'm fuzzy on what claim I made that MT is a counter to)
Comments
I push on this because the reader of the client-side code does not necessarily have the mental database of which types this is safe for. Each javadoc lookup is a readability point deduction.
(I'm fuzzy on what claim I made that MT is a counter to)