30

I'm looking at the new virtual extension methods in Java 8 interfaces:

public interface MyInterface {
   default String myMethod() { 
      return "myImplementation"; 
   }
}

I get their purpose in allowing an interface to evolve over time, and the multiple inheritance bit, but they look awfully like an abstract class to me.

If you're doing new work are abstract classes prefered over extension methods to provide implementation to an "interface" or are these two approaches conceptually equivalent?

Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
Kong
  • 8,792
  • 15
  • 68
  • 98
  • 8
    http://www.lambdafaq.org/do-default-methods-introduce-multiple-inheritance-to-java/ - the distinction between inheritance of behaviour vs. inheritance of state is crucial. – assylias Aug 13 '13 at 00:12
  • And [What are `default` methods?](http://www.lambdafaq.org/what-are-default-methods/) which pretty much lays out exactly their purpose. Their main purpose is to enable backwards compatibility with code that compiles against Java 7 and wouldn't implement any of the "functional" methods added to Java 8. – jason Aug 13 '13 at 00:16

4 Answers4

34

One primary purpose of such constructs is to preserve backwards compatibility. The addition of closures to the Java language is quite a major alteration, and things need to be updated to fully take advantage of this. For example, Collection in Java 8 will have methods such as forEach() which work in conjunction with lambdas. Simply adding such methods to the pre-existing Collection interface would not be feasible, since it would break backwards compatibility. A class I wrote in Java 7 implementing Collection would no longer compile since it would lack these methods. Consequently, these methods are introduced with a "default" implementation. If you know Scala, you can see that Java interfaces are becoming more like Scala traits.

As for interfaces vs abstract classes, the two are still different in Java 8; you still can't have a constructor in an interface, for example. Hence, the two approaches are not "conceptually equivalent" per se. Abstract classes are more structured and can have a state associated with them, whereas interfaces can not. You should use whichever makes more sense in the context of your program, just like you would do in Java 7 and below.

arshajii
  • 127,459
  • 24
  • 238
  • 287
5
  1. Abstract classes cannot be root classes of lambda expressions, while interfaces with virtual extension methods can be.
  2. Abstract classes can have constructors and member variables, while interfaces cannot. I believe its the execution of a possible constructor, and the possible throwing of a checked exception that prohibits abstract classes from being the root of a lambda expression.

If you want to write an API that allows the user to use lambda expressions, you should use interfaces instead.

Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
aepurniet
  • 1,719
  • 16
  • 24
5

Abstract classes hold state (instance fields), in order to provide some common behavior (methods).
You don't typically (ever?) see an abstract class without state.

Interfaces specify functionality. They are meant to declare behavior as a contract, not implement it.
Thus any methods that are specified as part of an interface are "helper" methods -- they don't affect the implementation.

user541686
  • 205,094
  • 128
  • 528
  • 886
  • 1
    `java.util.AbstractCollection`? It's normal for abstract classes not to have state. From Java SE 8, the fact that abstract classes can have instance state and interfaces with implementations cannot is just a language oddity. – Tom Hawtin - tackline Aug 13 '13 at 03:08
  • 1
    @TomHawtin-tackline: But if you look at the documentation for `AbstractCollection`, it says, *"This class provides a skeletal implementation of the `Collection` interface, to minimize the effort required to implement this interface."* In other words, it's just a convenience feature, but it doesn't need to be there for any particular design reasons. By contrast, `Collection` is *necessary* for writing generic code that works for all collections. – user541686 Aug 13 '13 at 08:11
  • I don't think that's relevant. It is true that abstract class often do not hold state. In Java SE 8 I believe `Collection` will contain some *"skeletal implementation of the `Collection` interface"* – Tom Hawtin - tackline Aug 13 '13 at 16:26
  • 1
    @TomHawtin-tackline: *"It is true that abstract class often do not hold state."*... would you mind naming some other such classes? – user541686 Aug 13 '13 at 16:37
0

Difference between Abstract class & functional interface are many like all the difference between a normal interface and abstract class but measure difference is we can have default methods in functional interface but not in abstract class, this changes and helped all the collection implementation in java 8 foreach() and other performance method with use of lambda 

package com.akhi;
public abstract class AbstractDemo {
abstract void letsRun(); // abstract valid
public String toString(); // invalid but valid in interface or functional interface

public boolean equals(Object o); // invalid but valid in interface or functional interface

public int concrete() { // Concrete is invalid in interface
    return 1;
}

public default int getMult(int a, int b) // default invalid but valid in case of functional
{
    return a * b;
}

public static int getSum(int a, int b) // static allowed
{
    return a + b;
}
}

Akhilesh
  • 89
  • 1
  • 6