HollowTypeAPI implements HollowRecordDelegate.

[kineshsatiya]

Hollow has two implementations for HollowRecordDelegate interface. An implementation of this interface is used by the HollowFactory when instantiating a HollowRecord. All the implementations of HollowRecord use the delegate instances to read data from the corresponding HollowTypeDataAccess. The flavors of the delegate interfaces are CachedImpl and LookupImpl. LookupImpl delegates all the reads to HollowTypeAPI. In order to reduce code generation and simplify the code generation, HollowTypeAPI now directly implements HollowRecordDelegate and the factory uses HollowTypeAPI as a delegate.

[PaulSandoz]

I have a general concern on the change and removal of public API artifacts before they have been marked as deprecated, rather than just focusing on not generating a client API artifact that is an implementation detail. Did you verify if these changes are compatible with generated client API code client prior to this change (since the client generated code generated by Hollow v1 can be can be operated on by a consumer using Hollow v2).

[PaulSandoz]

To answer my own question. I believe the changes to the protected constructor of HollowObjectTypeAPI will break existing generated client API code.

For example, the test HollowPrimitiveTypesAPIGeneratorTest will generate the following:

@SuppressWarnings("all")
public class ActorTypeAPI extends HollowObjectTypeAPI {

    private final ActorDelegateLookupImpl delegateLookupImpl;

    public ActorTypeAPI(PrimitiveTypeTestAPI api, HollowObjectTypeDataAccess typeDataAccess) {
        super(api, typeDataAccess, new String[] {
            "name",
            "role"
        });
        this.delegateLookupImpl = new ActorDelegateLookupImpl(this);
    }
    ...

It relies on the constructor of HollowObjectTypeAPI that accepts HollowAPI as the first parameter.