Should we prefer Composition over Inheritance when we can only use default constructor

I know the advantages of Composition over Inheritance but in some situation instances of the class are being created by framework using default constructor and we can not define constructor with parameter nor we can set attribute of the object using setter methods. To make this situation clear consider following example:

public class Main {

    public static void main(String... str){
        TargetFramework.component(Child.class);
    }
} 

Here the TargetFramework get a class and it will create instance of that class behind the scene using default Constructor.

Imagine I want to implement FramewrokInterface as below:

public interface FrameworkInterface {

    void setup();

    void doAction(Record record);

    void doAnotherAction(Record record, boolean isValid);
}

Now I can implement this interface in two ways considering Inheritance and Composition:

Approach 1: (Mixing and Matching Composition and Inheritance)

public abstract class Parent implements FrameworkInterface {

    RecordValidator recordValidator;

    @Override
    public abstract void setup();

    @Override
    public void doAction(Record record){
        boolean isValid = recordValidator.validate(record);
        doAnotherAction(record, isValid);
    }
    
    @Override
    public void doAnotherAction(Record record, boolean isValid){

    }
}

In this Implementation I decided to use composition and I've defined a RecordValidator as bellow:

public interface RecordValidator {
    boolean validate(Record record);
}

The problem here is that I can't set RecordValidator in Parent class when creating instance of this class because instances of this class are created by framework using default constructor but I can create this instance in setup method in child Class which extends parent class as below:

public class Child extends Parent {

    @Override
    public void setup() {
        recordValidator = new DefaultRecordValidator();
    }
}

The setup method of the FramworkInterface will be called just after instance created by default Constructor so we can use it to initialize our RecordValidator attribute; This is kind of Mixing and Matching Composition and Inheritance together to me because I'm using Composition with Inheritance together. However this approach has its own advantages because I've separated the Concern of validation of record from the Parent class Concerns.

Approach 2: (Just Inheritance)

In this approach I've implemented the FrameworkInterface in the following way:

public abstract class Parent1 implements FrameworkInterface {

    @Override
    public void setup() {

    }

    @Override
    public void doAction(Record record) {
        boolean isValid = validate(record);
        doAnotherAction(record, isValid);
    }

    @Override
    public void doAnotherAction(Record record, boolean isValid) {

    }

    protected abstract boolean validate(Record record);
}

This way instead of using composition and defining RecordValidator I've defined abstract validate method in my Parent1 class so that Child class can use it to implement validation behaviour, so the Child class can be implemented as follow:

public class Child extends Parent1 {

    @Override
    protected boolean validate(Record record) {
        return false;
    }
}

My question is:

Which approach is better for this situation and what are the pros and cons of them?

Which approach is better for this situation and what are the pros and cons of them?

I would argue that both of them are suboptimal to a degree where I would look for other solutions.

Looking at the sample code, there is, for example, no possibility to mock the dependencies of Child1 in both situations. You could introduce mock capabilities by implementing setters or special constructors that are only used for testing. The core problem I have with this setup, however, is that you bow to the framework.

I would recommend exploring other possibilities, e.g. do the necessary dependency injection manually, then "register" a finished bean with the framework. This is what Uncle Bob means when he talks about keeping the framework at arm's length.

If we start talking about Java in particular and the framework does not allow any other solution to, e.g., create beans beforehand and registering them with the framework, I would contact the framework maintainers and ask to implement CDI support since this is a standardized way to handle Depencency Injection.

Looking at your example, you take two different approaches, i.e. you redefine the capabilites of Parent. Just as you did with Parent in the inheritance example, you could define abstract boolean validate(); in Parent, delegating the implementation to Child. I would even go a step further and define

public interface class Parent extends FrameworkInterface, RecordValidator {
    ...
}

(all methods in Parent are either abstract or can be seen as defaults, the field can be removed). Thus, each class implementing this interface implements the methods as it sees fit.