Java Bindings: Generate classes for contract keys

Dealing with Contract Keys in a typed manner is very difficult at the moment:

A contract key can be a variety of different types (anything Value.class returns). This leads to the actual java type being a simple String, a Daml Tuple.class or full classes generated by codegen.

This leads to complex type handling on a per Template basis having to understand what Value will be returned and handle it.

It would be much easier if ContractKey classes were always generated instead of the “sometimes yes and sometimes no”.

What is the solution you would propose?

as described here: https://discuss.daml.com/t/input-limit-on-template-key/3029/3?u=stephenott there are multiple ways a template key could be established in the daml template.

It would be nice if the codegen generated a contract key class for each Template’s contract key so we can work in a typed manner that is closer to the template instead of working with the complex variation that is returned by the DamlRecord.

Even if a contract key was a single field such as a string it would still be wrapped into the generated class representing the ContractKey for the specific template.

Further this would simplify dealing with TransactionTree results where the contractKey is being returned outside of the contract class that was generated (because contractKey is a field in CreatedEvent vs where a Template’s inner “Contract” class has a typed contractKey field)

[S11001001]

The ContractId class is currently being used to provide access to the exercise commands. Vs for exercideByKey commands they have been added into the root of Template class.

@StephenOTT Regarding exercise specifically, this has been significantly reworked in the forthcoming Daml 2.3.x; see the changelog in #14037, and note how Exercises relates to ContractId and ByKey in the updated documentation.

[S11001001]

@StephenOTT If you are interested in reading LF (the compiled format of Daml) and navigating it, please see this forum comment (note that interface library is now called api-type-signature to avoid confusion with Daml interfaces).

The caveats about all those possibilities mentioned in that discussion still apply – api-type-signature is an internal library and not subject to any stability guarantees – but, for what it’s worth, Java codegen itself uses the the api-type-signature library to load an input AST from LF.

I recommend directing further discussion along the lines of parsing LF to the forum; there are a few threads such as the above-linked with similar queries that may be informative as well.