Comment 1 Sebastian Zarnekow 2015-04-01 08:22:40 EDT

Abstract classes may have state which introduces some more complexity when it comes to the decision: override an existing method and delegate, or keep it as inherited. Could you give an example on your usecase?

Comment 2 Anton Kosyakov 2015-04-01 09:33:18 EDT

It is not related only to abstract classes but to wrapping any type in general.

Consider the following case with current logic:
interface Foo {
  def void setValue(String value)
}

class FooImpl implements Foo {
  String value
  def void setValue(String value) {
    this.value = value
  }  
  def getValue() {
    value
  }
}

class Bar extends FooImpl {
  @Delegate
  FooImpl foo
}

In such case one get exactly the same issue which you described:
1. Bar#setValue changes a state of the delegate;
2. Bar.getValue reads a local state.

I was really confused by it when tried to wrap JavaIoFileSystemAccess for Intellij and ended up subclassing. It is not totally correct because if somebody has their own subclass of JavaIoFileSystemAccess, they won't get it in Intellij but rather which I created.

Also sometimes you cannot subclass or extract an interface, for example if an instance is created by some framework, but still want to add new behavior by delegating.

Maybe having some checks will be better than limiting to interfaces?