Hacker News Reader

Comment by nomercy400 | Hacker News Reader

Doesn't this break every existing implementation of List/Deque/SortedSet, as now every implementation is missing the new interface methods?

So suddenly updating from Java N to Java N+1 will no longer compile your code.

View on HN

Since Java 8, there are default interface method implementations: https://docs.oracle.com/javase/tutorial/java/IandI/defaultme... . You can add any method to interface in backward-compatible way if you also define default implementation.

This is solved by default methods in the interfaces.

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.

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?

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.

Java 8 introduced default method, exactly to cover cases like this. Presumably custom implementation would result in exception.

Reply on news.ycombinator.com