> In general you need to recompile the subclass if the superclass changes.
This just isn’t true. There are compatible changes and incompatible changes you can make.
Having the soundness of the compiler rely on the assumption that there won’t be any changes just isn’t viable. For example, the thread-safety guarantees provided by final fields would be difficult to ensure.
> This just isn’t true. There are compatible changes and incompatible changes you can make.
This statement exactly applies to the case you mentioned: Superclass implementations can change later (you can recompile the superclass without having to recompile the subclass), you can’t assume their current implementation will stay the same.
For me these are on two different levels. The guarantees about final fields being assigned exactly once, and the related thread-safety guarantees, are part of the soundness of the language. Late binding may fail and you'll get a NoSuchMethodError or similar, that's fine. But you won't get an Error thrown if suddenly your fields fail to initialize or your class stops being thread-safe just because the superclass implementation changed.
This just isn’t true. There are compatible changes and incompatible changes you can make.
Having the soundness of the compiler rely on the assumption that there won’t be any changes just isn’t viable. For example, the thread-safety guarantees provided by final fields would be difficult to ensure.