为何`Throwable.detailMessage`未被声明为final？该字段仅构造时修改、仅getMessage访问

Great question! Let's break down the reasoning behind this design choice, even though the field seems like it should be final at first glance:

• Serialization Flexibility: Throwable implements Serializable, and in early Java versions (pre-1.2), handling final fields during deserialization was far more restrictive. Making detailMessage non-final allowed the class's private deserialization logic (via the readObject method) to directly assign the value without needing clunky workarounds like reflection to modify a final field. While modern Java handles final fields in serialization more smoothly, this design was retained for backward compatibility.

• Legacy Code Compatibility: Before stricter encapsulation norms became standard, some unoffical legacy code might have used reflection to modify detailMessage (even though this was never supported by the Java API). Keeping the field non-final ensured this code wouldn't break when new Java versions rolled out.

• Subclass Considerations: Even though detailMessage is private, there's historical context where some specialized Throwable subclasses might have relied on indirect ways to adjust this field (via internal APIs or reflection). Making it final could have inadvertently broken these implementations, which the Java development team aimed to avoid.

It's important to note that even without the final modifier, the public API of Throwable enforces immutability: there's no public method to modify detailMessage after construction. From a developer's perspective, it behaves exactly like a final field— the non-final declaration is purely about internal implementation and maintaining compatibility with older codebases.

内容的提问来源于stack exchange，提问作者Dean Xu