Thanks for reporting this! I’ve opened an issue for it.
I’ve read a few confusing things in this thread, so here are a few clarifications for future readers.
For various historical reasons, in the 0.x.y releases of the DAML SDK (now Daml Connect SDK), Java libraries had corresponding 100.x.y version numbers. Since 1.0.0, version numbers match, and while there has been a couple renamings (as @cocreature mentioned), I don’t thnk we’ve dropped anything (yet).
The daml build command builds Daml-LF bytecode based on Daml source code, and packages it in the form of DAR files. In order to generate type definitions in other languages, one must use the daml codegen command(s).
Our Java bindings (and Java codegen) target the protobuf/gRPC Ledger API, while our TypeScript bindings (@daml/ledger & @daml/type) and codegen target the JSON/HTTP API. We also provide a completely optional React-specific library (@daml/react) that builds on top of our TypeScript bindings.
Navigator is a separate, standalone (dev-time-only) tool not tied to any codegen, bindings or Daml Studio.
1 Like
great, meaning that from my perspective all I need is the java generated bindings which I can attach to from my Groovy JavaFX code to manipulate and query the ledger and have no need whatsoever for any json/http api, which I was unclear of where the division was.
Sounds good.
Does a runtime daml ledger explorer exist ?
thanks
1 Like
Navigator would function as this for getting a view of the active contracts and templates accessible to a specific party. Daml is strongly permissioned so views are always local to a specific party.
There are also other options depending on your needs:
- The active contract service and transaction service (for historical data) which you can get over the gRPC Ledger API
- An early access feature called Extractor that can pull historical/archived contracts and active contracts from any deployment using Daml for Postgres