4 ms·

You could also remove a method from the superclass entirely in such a situation. This would cause an invocation of the removed method to fail if the subclass de

by rcme 4y ago

You could also remove a method from the superclass entirely in such a situation. This would cause an invocation of the removed method to fail if the subclass depended on it. In general you need to recompile the subclass if the superclass changes.

layer8 4y ago
> 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.
- rcme 4y ago
  > 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.
  - layer8 4y ago
    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.
tsimionescu 4y ago
> In general you need to recompile the subclass if the superclass changes. If you are using "in general" in the sense of "in the general case", you are right. But if you are using it as "typically", then that's not true - it's very common for example for a library to be compiled with Java X while subclassing at least a few standard library classes, and then to keep using the same compiled classes with Java X+1, X+2, and to expect them to just work. The Java Standard Library actually takes quite a bit of care to make sure modifications to its (non-final) classes are backwards compatible even for subclasses.

by rcme 4y ago

layer8 4y ago

> 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.

rcme 4y ago
> 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.
- layer8 4y ago
  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.

tsimionescu 4y ago

> In general you need to recompile the subclass if the superclass changes. If you are using "in general" in the sense of "in the general case", you are right. But if you are using it as "typically", then that's not true - it's very common for example for a library to be compiled with Java X while subclassing at least a few standard library classes, and then to keep using the same compiled classes with Java X+1, X+2, and to expect them to just work. The Java Standard Library actually takes quite a bit of care to make sure modifications to its (non-final) classes are backwards compatible even for subclasses.