@stefanobaghino-da thanks for the detailed feedback.
The Java Bindings are just a GRPC Client. it is no different then using a OpenAPI spect to generate a HTTP Client. You are suggesting that “we can’t trust developers” to use a GRPC client and adapt that client to the business needs. The issue with the final classes is a developer level code conversation around creating productive developers in the community. Your description is more around product usage at a sales level of the ledger.
The bindings / codegen is generating a gRPC client for the Ledger API. It is not a application or really any sort of opinionated interface. It is a gRPC client.
This builds on my comment above about code productivity conversation vs “product” conversation: The example of the DamlClient not having the party allocation is an example of developer’s need to enhance the generated code for productivity purposes: People have been asking about the party allocation service in the java bindings since at least April 2020 (Java Bindings do not have all Ledger API services). No one would ever expect that every feature, function, and capability be provided on day 1. Product takes time, limited resources, etc. But by applying final on classes (inconsistently in many cases: Template classes have final, but choice classes do not, and Record classes do not), we are killing developer productivity to build business applications and re-use the provided classes / baseline.