[http-client-java] mgmt, if resource model is immutable output, innerModel can't be initialized in fluent model implementation ctor

[XiaofeiCao]

https://github.com/Azure/azure-rest-api-specs/pull/34322/checks?check_run_id=42881265079

The XXInner model is only used in output, since PUT request is using another model.
https://github.com/Azure/azure-rest-api-specs/blob/8ab62e07ff4f8966e00072b2a634c817a2b57971/specification/nginx/Nginx.Management/NginxConfigurationResponse.tsp#L40-L53

createOrUpdate is Azure.ResourceManager.Legacy.UpdateOperation<
  ResourceInstanceParameters<
    NginxConfigurationResponse,
    Azure.ResourceManager.Foundations.DefaultBaseParameters<NginxConfigurationResponse>
  >,
  NginxConfigurationRequest,
  NginxConfigurationResponse | ArmResourceCreatedResponse<
    NginxConfigurationResponse,
    LroHeaders = ArmAsyncOperationHeader<FinalResult = NginxConfigurationResponse>
  >,
  ErrorResponse,
  OptionalRequestBody = true
>;

In current resource model implementation, we'll initialize innerModel in ctor by name:

NginxConfigurationResponseImpl(String name, com.azure.resourcemanager.nginx.NginxManager serviceManager) {
    this.innerObject = new NginxConfigurationResponseInner();
    this.serviceManager = serviceManager;
    this.configurationName = name;
    this.createBody = new NginxConfigurationRequest();
}

NginxConfigurationResponseInner is output immutable model and only has private ctor, which cannot be initialized.

Possible solution would be,

1. Do not initialize it in ctor by name, and in simple property methods, check innerModel() != null before returning, e.g.

if (this.innerModel() != null) {
  return this.innerModel().systemData();
}

Though should check other references.

2. When model is used as fluent response(xxInner), make the ctor public. This is probably not good, since output only model shouldn't be initialized by client(either us or user).

[weidongxu-microsoft]

One wondering is whether there is a need for the ctor (without innerObject).

E.g. a Impl of read-only model could be the Operation from the Operations_List API.

public final class OperationImpl implements Operation {
    private OperationInner innerObject;

    private final com.azure.resourcemanager.avs.AvsManager serviceManager;

    OperationImpl(OperationInner innerObject, com.azure.resourcemanager.avs.AvsManager serviceManager) {
        this.innerObject = innerObject;
        this.serviceManager = serviceManager;
    }

    public String name() {
        return this.innerModel().name();
    }

    public Boolean isDataAction() {
        return this.innerModel().isDataAction();
    }

    public OperationDisplay display() {
        return this.innerModel().display();
    }

    public Origin origin() {
        return this.innerModel().origin();
    }

    public ActionType actionType() {
        return this.innerModel().actionType();
    }

    public OperationInner innerModel() {
        return this.innerObject;
    }

    private com.azure.resourcemanager.avs.AvsManager manager() {
        return this.serviceManager;
    }
}

And it does not that ctor.

[XiaofeiCao]

This ctor is only used in define method.

public NginxConfigurationResponseImpl define(String name) {
    return new NginxConfigurationResponseImpl(name, this.manager());
}

We don't need to initialize this innerModel, if it's not used in create/update flow.

[weidongxu-microsoft]

This ctor is only used in define method.

public NginxConfigurationResponseImpl define(String name) {
return new NginxConfigurationResponseImpl(name, this.manager());
}
We don't need to initialize this innerModel, if it's not used in create/update flow.

Got it. In such case, we may not even need the null protection on getters. When create the resource, user cannot call getter; when the resource is created (or retrieved), the innerObject should be there.

[XiaofeiCao]

I see. Yes, for getters, we could ignore this null protection.

Except for getters, we may need the protection in isInCreateMode method:

    private boolean isInCreateMode() {
        return this.innerModel().id() == null;
    }

    public NginxConfigurationResponseImpl withProperties(NginxConfigurationRequestProperties properties) {
        if (isInCreateMode()) {
            this.createBody.withProperties(properties);
            return this;
        } else {
            this.updateBody.withProperties(properties);
            return this;
        }
    }

I think this should be the only exception.