-2

I got the point that default methods, that where provided in java 8 interfaces can reduce code that should be written in implementations. It's clear. But I cannot get the point, why adding this feature to language protects us from backward incompatibility?

If, let's say, we've added the new method to the interface List, then we could simply implement it where it's needed (ArrayList, LinkedList ,etc.) event with no default method implementation?

Where does the exact incompatibility hide itself? What can be broken with no default methods?

Here question is about breaking source compatibility but my question is a bit another - about saving it.

Vladyslav Nikolaiev
  • 1,819
  • 3
  • 20
  • 39
  • Please read about functional interface and stream API. That will help you to understand. – iamrajshah Jan 24 '19 at 12:58
  • @iamrajshah, after reading I had an impression that JDK developers was simply lazy to add implementation of new methods of List interface to each JDK List implementation and decided to leave it in within the interface. But now I got that where can be custom List implementation that might be broken in others code. – Vladyslav Nikolaiev Jan 24 '19 at 13:17
  • I think people just don’t seem to simplify this concept of interface default methods & backward compatibility. When you add a new method to an interface (public abstract) it forces every subclass downstream to implement it. This has the potential to spoil many user libraries. Default methods are too classified as instance methods but they are already implemented at the interface so nothing downstream should break. It may break if a class implements two interfaces with 2 default methods with a similar signature, and it will ultimately require a local class implementation to fix it. – downvoteit Nov 24 '22 at 09:12

1 Answers1

4

If, let's say, we've added the new method to the interface List, then we could simply implement it where it's needed (ArrayList, LinkedList ,etc.) event with no default method implementation?

How do you do that when you do not control all implementations of List? You (meaning the Java Gods) can add it in the JDK, but how about all the implementations in other people's code? Those would not compile anymore. And if someone tried to call one of the new methods on their implementation (from a previously compiled JAR file) they'd get a nasty MethodNotFoundError at runtime.

Backwards compatibility means that existing code can work without modifications. In this case, they aim for source compatibility, which means you can compile the same source code without changes against the new Java version. The other thing is binary compatibility, which means that old compiled classes continue to work (which Java is famous for).

Source compatibility has been broken from time to time (for example the JDBC API is notorious for getting new interface methods all the time), but not in such a central class such as List (the JDBC changes only affected database driver vendors, not application code).

So without default methods, no new methods could have been added to the List interface. It would have needed to be an additional EnhancedList or ListV8 (that all JDK lists would have implemented but all using code would have needed to refactor to make use of).

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • _You (meaning the Java Gods) can add it in the JDK, but how about all the implementations in other people's code? They would not compile anymore._ So, under compiling you **only** meant **custom** List implementations? – Vladyslav Nikolaiev Jan 24 '19 at 13:08
  • If you add a new method to an interface, no existing implementation will compile anymore. All of them need to be amended for the new method. This includes source code under your control as well as (if you have shipped your interface as part of a library) other people's code. – Thilo Jan 24 '19 at 13:12