Reports

What if we cheat a little? Let's look at a use case:

I manage a field, my system has the classes Watermelon, Tractor, and Cow, which are obviously incompatible from an inheritance standpoint, extending to Vegetable, Machinery, and Animal respectively. All of them represent an object that has economic value, so I need them to have the value attribute and the associated setters and getters. I can implement what is repetitive (and yes, tedious) in each of the classes, and I would still have extra work if I want to know the cumulative value of all my assets.

Now that you've seen the problem, imagine that instead of Machinery and its sisters, you have a hundred types to extend...

Laziness is what drives me.

Let's get on with the implementation:

public abstract class Animal implements Value {

   Helper helper;
   
   @Override
   public Helper getHelper() {
      return helper;  
   }
}

public class Cow extends Animal {

   public Cow() {
      helper = new Helper();
   }
}

public abstract class Machinery implements Value {

   Helper helper;

   @Override
   public Helper getHelper() {
      return helper;  
   }
}

public class Tractor extends Machinery {

   public Tractor() {
      helper = new Helper();
   }   
}

public abstract class Vegetable implements Value {

   Helper helper;

   @Override
   public Helper getHelper() {
      return helper;  
   }
}

public class Watermelon extends Vegetable {
   
   public Watermelon() {
      helper = new Helper();
   }
}

As you can see, we have three abstract classes, which have a Helper object as an attribute and a method that returns it. The three classes are extended by their respective children, which instantiate the Helper object in their constructor.
Obviously, these classes are greatly simplified.
This Helper is responsible for “storing” the attributes we need. The interface has no attributes (which would be static and therefore the same for all instances), so it remains “stateless.” It is only responsible for implementing the methods to interact with the Helper object so that, seen from the “outside,” its attributes appear to be part of the class that contains it.

public class Helper {

   int value;
   
   public int getValue() {
      return value;
   }
   
   public void setValue( int v ) {
      value = v;
   }
}

public interface Value {

   default int getValue() {
      return getHelper().getValue();
   }
   
   default void setValue( int v ) {
      getHelper().setValue( v );
   }
   
   Helper getHelper();
}

Testing...

public class Main {

   List<Value> listOf;
   
   void init() {
      listOf = new ArrayList<>();
      Cow cow = new Cow();
      cow.setValue( 10 );
      listOf.add( cow );
      Watermelon watermelon = new Watermelon();
      watermelon.setValue( 1 );
      listOf.add( watermelon );
      Tractor tractor = new Tractor();
      tractor.setValue( 500 );
      listOf.add( tractor );
      int myCapital = 0;
      for( Value value : listOf ) {
         myCapital += value.getValue();
      }
      System.out.println( myCapital );  //  print "511"
   }
   
   public static void main( String[] args ) {
      new Main().init();
   }
}

Notes: The names Helper and Value could clearly be improved.
This could be considered “multiple inheritance disguise”... or not?