non-reflective abstractions for Java codegen Contracts #13724

S11001001 · 2022-04-27T16:25:51Z

Fixes #13471. readActiveContractKeys and readActiveContractPayloads are simple examples of functions that would not have been possible to write before.

well-typed parents for generated ContractId and Contract
move a bunch of things to these classes instead of code-generating them
static COMPANION as a now-and-future home for well-typed abstractions over things that are currently just static methods

Eta-expanding static methods into functions works for many use cases. But it doesn't really let us build stuff on top of those methods once, without "infectious codegen". An example is the new fromCreatedEvent: this method is now hand-written, with only static forwarding shims codegenned.

Other things can usefully be moved into ContractCompanion and its signature and hierarchy usefully expanded. fromValue is a really good candidate. But this PR is doing quite enough.

CHANGELOG_BEGIN
- [daml codegen js] Generated templates have types, inherited methods,
  and a new static ``COMPANION`` that enable writing more
  template-generic utilities directly in Java.  New classes
  ``Contract``, ``ContractWithKey``, and ``ContractCompanion``, have
  been introduced; if you are importing
  ``com.daml.ledger.javaapi.data.codegen.*`` and have imported classes
  with these names from any other package, these references will stop
  working; use individual imports instead.
  See `issue #13724 <https://github.com/digital-asset/daml/pull/13724>`__.
CHANGELOG_END

keyed contracts
companion
eliminate generated contract toString?
test abstract usage
changelog
remove abstract deprecated method, not needed for static forwarders
make Contract vs ContractWithKey more like ContractCompanion.WithoutKey vs ContractCompanion.WithKey?
call ContractCompanion TemplateCompanion instead, as with Scala codegen?

…va-codegen-contract-abstract-methods

CHANGELOG_BEGIN - [daml codegen js] Generated templates have types, inherited methods, and a new static ``COMPANION`` that enable writing more template-generic utilities directly in Java. See `issue #13724 <https://github.com/digital-asset/daml/pull/13724>`__. CHANGELOG_END

...port/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractCompanion.java

stefanobaghino-da

Adding a blocker to make sure a few important points don't go unaddressed:

If a client changes a Daml model, upgrades to a new version where this PR got merged and re-generates code purely with the intent of generating code for the changed Daml models, will existing client code cease to compile, raise compilation warnings or change runtime behavior?
How does this feature interact with the decoder class? Is there a change in approach enabled by this change?
This adds a new feature and/or changes the way in which an existing feature can be changed: is this sufficiently documented to enable users to start using this independently after going through the documentation?

S11001001 · 2022-05-02T17:00:40Z

If a client changes a Daml model, upgrades to a new version where this PR got merged and re-generates code purely with the intent of generating code for the changed Daml models, will existing client code cease to compile,

@stefanobaghino-da Their code may fail javac if they import com.daml.ledger.javaapi.data.codegen.* and also com.daml.ledger.javaapi.data.Contract (wildcard or no), and refer to Contract. No warnings or behavior changes.

raise compilation warnings or change runtime behavior?

No.

How does this feature interact with the decoder class?

Not in this PR.

Is there a change in approach enabled by this change?

Yes, discussed in #13768.

This adds a new feature and/or changes the way in which an existing feature can be changed: is this sufficiently documented to enable users to start using this independently after going through the documentation?

A user who is motivated to build the kinds of template-generic functions this PR enables should find all they need to know in the type signatures, with the understanding that they are just like the static methods of the same signature.

If we were happy with the documentation of fromCreatedEvent before, then this feature offers exactly the same experience. If we want to expand on that, the Javadoc is the best place to do so; I do not think docs.daml.com should cover this in detail other than to mention that it is generated, as the example here does.

stefanobaghino-da · 2022-05-06T16:27:01Z

@stefanobaghino-da Their code may fail javac if they import com.daml.ledger.javaapi.data.codegen.* and also com.daml.ledger.javaapi.data.Contract (wildcard or no), and refer to Contract. No warnings or behavior changes.

Please add this consideration to the change log so that the release coordinator can be aware of this. It's very important that we minimize the impact of changes and give a clear explanation on how to migrate if there is an impact. I'll remove my blocker in light of your replies. Thanks.

Concerns addressed in #13724 (comment)

CHANGELOG_BEGIN - [daml codegen js] Generated templates have types, inherited methods, and a new static ``COMPANION`` that enable writing more template-generic utilities directly in Java. New classes ``Contract``, ``ContractWithKey``, and ``ContractCompanion``, have been introduced; if you are importing ``com.daml.ledger.javaapi.data.codegen.*`` and have imported classes with these names from any other package, these references will stop working; use individual imports instead. See `issue #13724 <https://github.com/digital-asset/daml/pull/13724>`__. CHANGELOG_END

…va-codegen-contract-abstract-methods

@ray-roestenburg-da

- suggested by @ray-roestenburg-da; thanks

shift some generated Contract code to a handwritten superclass

72ae4dc

S11001001 added component/java-ecosystem Java development experience team/ledger-clients Related to the Ledger Clients team's components. labels Apr 27, 2022

S11001001 self-assigned this Apr 27, 2022

support contracts with keys as well

5d43d23

S11001001 mentioned this pull request Apr 27, 2022

[FEATURE REQUEST] Make Java codegen more OO friendly by adding contract methods to empty contract Interface #13471

Closed

S11001001 added 24 commits April 27, 2022 13:49

companion types for templates and contracts

f6aada1

simplify the key-dependent generator branches

99837d0

reformulate ContractCompanion so generated code doesn't have to subclass

32b2b85

generate a COMPANION for each template

d11ccd8

missing @FunctionalInterface

da92178

slightly smaller companion constructor

70cb4c8

optional newlines for a nicer constructor call

2ea9e9d

fromIdAndRecord is a static forwarder

4a02c9b

encapsulate the idea of a static forwarder to companion

ca8fb95

replace fromCreatedEvent with a forwarder

173b87a

reformulate companion forwarder without generating patterns

23cccf8

deprecated fromIdAndRecord is a companion forwarder

6430ef0

small reformat

d6059cd

remove magic strings TEMPLATE_ID and COMPANION

345fde8

Merge commit '615d2e62068c0213b8c43f2a73f7ef2ead23744f' into 13471-ja…

5b2ba1c

…va-codegen-contract-abstract-methods

simpler super constructor derivation

8f2f077

reformat

c458134

link Contract to its companion

67672f7

do not generate toString for Contract

a18e73d

note on getCompanion type

4694cef

use the companion in some ledger reading tests

2af8bd0

test the companion's fromCreatedEvent and Contract's toString

789183e

document changes in template Java codegen

77f7df3

S11001001 marked this pull request as ready for review April 29, 2022 21:20

S11001001 requested review from stefanobaghino-da and ray-roestenburg-da as code owners April 29, 2022 21:20

S11001001 requested a review from realvictorprm April 29, 2022 21:20

ray-roestenburg-da reviewed Apr 30, 2022

View reviewed changes

...port/java/bindings/src/main/java/com/daml/ledger/javaapi/data/codegen/ContractCompanion.java Outdated Show resolved Hide resolved

ray-roestenburg-da approved these changes Apr 30, 2022

View reviewed changes

stefanobaghino-da previously requested changes May 2, 2022

View reviewed changes

This was referenced May 2, 2022

make switch-on-template-ID decoder classes a concrete part of bindings #13768

Closed

remove fromIdAndRecord(String, DamlRecord) from codegen output #13773

Closed

S11001001 requested a review from stefanobaghino-da May 2, 2022 17:02

S11001001 added 3 commits May 6, 2022 13:49

Merge commit '1b4f9bb2f8f6fb6139d694764f039e9c37d26978' into 13471-ja…

6b53ca1

…va-codegen-contract-abstract-methods

remove unused abstract method; note deprecation times

0de313e

- suggested by @ray-roestenburg-da; thanks

S11001001 enabled auto-merge (squash) May 6, 2022 18:00

S11001001 merged commit 226dcc0 into main May 6, 2022

S11001001 deleted the 13471-java-codegen-contract-abstract-methods branch May 6, 2022 18:47

S11001001 mentioned this pull request May 23, 2022

javadocs for codegen support in javaapi bindings #13959

Merged

This was referenced Jun 30, 2022

Decoder types for Java codegen #14313

Closed

Apply interfaces to generated classes: Templates, Data Objects, Choices + CreatedEvent Core contract data #14331

Open

S11001001 mentioned this pull request Nov 22, 2022

remove generated Contract subclasses #15662

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

non-reflective abstractions for Java codegen Contracts #13724

non-reflective abstractions for Java codegen Contracts #13724

S11001001 commented Apr 27, 2022 •

edited

Loading

stefanobaghino-da left a comment

S11001001 commented May 2, 2022

stefanobaghino-da commented May 6, 2022

non-reflective abstractions for Java codegen Contracts #13724

non-reflective abstractions for Java codegen Contracts #13724

Conversation

S11001001 commented Apr 27, 2022 • edited Loading

stefanobaghino-da left a comment

Choose a reason for hiding this comment

S11001001 commented May 2, 2022

stefanobaghino-da commented May 6, 2022

S11001001 commented Apr 27, 2022 •

edited

Loading