3 ms·

This is solved by default methods in the interfaces.

erik_seaberg 4y ago
They did acknowledge > Introducing new methods high in the inheritance hierarchy runs the risk of clashes over obvious method names such as reversed and getFirst. > We will analyze a large corpus of Java code in order to assess these risks.
- int_19h 4y ago
  Heh, so Hejlsberg was right, except they didn't go far enough (in C#, unlike Java, methods in classes aren't overridable by default and all overrides must be explicit - but implementing interfaces can be implicit, so this case can still cause quiet breakage). How does JVM handle this at runtime if you don't recompile, though? In CLR, on IL level, interface implementations and overrides both explicitly designate the original method they override/implement - so even if an already-compiled class has a method with the same name and signature as the newly added interface method, it wouldn't be considered an implementation of that method until you recompile the class against the new interface. But in JVM, isn't it handled by name at runtime as well?
  - pron 4y ago
    Forcing the use of something like @Override wouldn't have mattered because dispatch is dynamic -- it would only trigger a compilation error when recompiling from source. At runtime, if the methods have a different (and incompatible) return type then the original method would be called because the JVM does allow overloads that differ by return types, but the Java language doesn't, so already-compiled code would work as before, but it wouldn't compile from source (that's a source incompatibility, which is not as important in Java as binary compatibility). If the methods do have a matching signature to the default ones, then they will be called when the interface method is invoked, as overrides of the default methods. If, additionally, their behaviour is not one that conforms to the new interface's specification, that could be a problem. That's why a corpus analysis is needed, to see how frequently such methods were added in subclasses.
  - deleted 4y ago
    [deleted]

They did acknowledge > Introducing new methods high in the inheritance hierarchy runs the risk of clashes over obvious method names such as reversed and getFirst. > We will analyze a large corpus of Java code in order to assess these risks.

int_19h 4y ago
Heh, so Hejlsberg was right, except they didn't go far enough (in C#, unlike Java, methods in classes aren't overridable by default and all overrides must be explicit - but implementing interfaces can be implicit, so this case can still cause quiet breakage). How does JVM handle this at runtime if you don't recompile, though? In CLR, on IL level, interface implementations and overrides both explicitly designate the original method they override/implement - so even if an already-compiled class has a method with the same name and signature as the newly added interface method, it wouldn't be considered an implementation of that method until you recompile the class against the new interface. But in JVM, isn't it handled by name at runtime as well?
- pron 4y ago
  Forcing the use of something like @Override wouldn't have mattered because dispatch is dynamic -- it would only trigger a compilation error when recompiling from source. At runtime, if the methods have a different (and incompatible) return type then the original method would be called because the JVM does allow overloads that differ by return types, but the Java language doesn't, so already-compiled code would work as before, but it wouldn't compile from source (that's a source incompatibility, which is not as important in Java as binary compatibility). If the methods do have a matching signature to the default ones, then they will be called when the interface method is invoked, as overrides of the default methods. If, additionally, their behaviour is not one that conforms to the new interface's specification, that could be a problem. That's why a corpus analysis is needed, to see how frequently such methods were added in subclasses.
- deleted 4y ago
  [deleted]