1.0.1

This is a bugfix release for SDK 1.0.0. All users of SDK 1.0.0 are
encouraged to upgrade at their earliest convenience. This release fixes
3 issues:

1. Fix an issue with false negative contract key lookups by
   non-stakeholders (see
   #5562 for details).

   This issue affected the new Sandbox introduced in SDK 1.0.0 (but not
   sandbox-classic) as well as the scenario service. Both Sandbox and
   the scenario service are fixed.

2. Fix a crash in the scenario service.

   SDK 1.0 introduced a bug where the scenario service would crash if a
   failing transaction contained transient contracts. In DAML Studio
   this was shown as the following error:

BErrorClient (ClientIOError (GRPCIOBadStatusCode StatusUnknown (StatusDetails {unStatusDetails = \“\”})))

3. Fix an issue where Sandbox incorrectly rejected certain commands
   relying on getTime during validation (see
   #5662 for details).
   This was only an issue if you set either min_ledger_time_rel or
   min_ledger_time_abs.

v1.0.1-snapshot.20200424.3917.0.16093690

Backport "Remove duplicate ledger time field (#5698)" (#5713)

The duplicated information was not always in sync.

Fixes #5662

CHANGELOG_BEGIN
- [Sandbox] Fix an issue where the sandbox would sometimes reject transactions
  with a "INVALID_ARGUMENT: Disputed" error if either of
  ``min_ledger_time_rel`` or ``min_ledger_time_abs`` was set in the
  submission request.
CHANGELOG_END

Co-authored-by: Robert Autenrieth <[email protected]>

1.1.0-snapshot.20200422.3991.0.6391ee9f

This is a snapshot release. Use at your own risk.

v1.0.1-snapshot.20200417.3908.1.722bac90

This is a snapshot release. Use at your own risks.

1.0.0

Summary

• New JavaScript/TypeScript client-side tooling is now stable and the
  recommended way to build DAML applications. A new Getting Started
  Guide based
  on these tools has replaced the Quickstart guide.
• The Time Model has been improved so that it works seamlessly without
  user input to the Ledger API. Action needed when you update to the
  latest version of API bindings or recompile gRPC clients.
• More TLS configuration options for DAML Ledgers.
• The next generation Sandbox is now the default, bringing an
  experience closer to a distributed ledger. Immediate action is
  needed if your project is relying on scenarios for ledger
  initialization.
• Cleanup of names, deprecated features and language versions.
  Immediate action needed if you use any Java dependencies with
  com.digitalasset packages or Maven coordinates.

Known issues

• The new Sandbox has a known issue where some false negative contract
  key lookups are only correctly validated on the read path, not on
  the write path. The net effect is that with carefully constructed
  DAML models, non-conformant transactions can be recorded in the
  underlying storage, which may lead to data continuity issues when
  this issue is fixed. Full details can be found on GitHub issue
  #5563.

What's New

New Client Tooling

Background

Distributed applications are much more than smart contracts running on a
distributed ledger, and in 2019 we set out to make it significantly
easier to build that part of applications which lives off-ledger:
Automations, Integrations, and UIs. The new tooling is focused on giving
application developers an easy-to-consume, real-time ledger state, which
moves the development experience away from event sourcing and makes it
similar to working with a database.

• The HTTP JSON API: giving a queryable view of the ledger state and
  endpoints to submit transactions, all using an easy-to-consume JSON
  format.
• A JavaScript/TypeScript code generator: turning a DAML package into
  a (typed) library to interact with the HTTP JSON API.
• A set of JavaScript/TypeScript client libraries: working hand in
  hand with the code generator to interact with the HTTP JSON API, and
  bind ledger data to React components.
• A new Getting Started Guide shows how all these pieces fit together
  to build a complete distributed end-to-end application with a custom
  UI.

The HTTP JSON API is designed to be consumable from any language
ecosystem. The choice of JavaScript (and React) for the rest of the
tooling was driven by the desire to aid application development all the
way up to UIs, using the most widely adopted technologies.

Specific Changes

• The documentation has a new Getting Started
  Guide. The
  previous Quickstart guide has moved under the Java Bindings section.
• There is a new SDK template with a skeleton for an end-to-end
  application using the new tooling. It's documented and used in the
  new Getting Started Guide. Use
  daml new create-daml-app create-daml-app to get started.
• The /v1 endpoints of the HTTP JSON API and the JavaScript Code
  Generator and Support Libraries are now stable.
  • The JSON API has gained an endpoint to allocate parties:
    /v1/parties/allocate.
• Support for maps and lists has been removed from the query language.
• Note that the WebSockets streaming endpoint of the HTTP JSON API is
  still under development.

Impact and Migration

The new client tooling is almost purely additive so for most, no action
is needed. For new applications, we recommend this tooling as it makes a
lot of things quicker and easier. However, direct use of the Ledger API
and HTTP JSON API continues to be a good option for anyone needing
lower-level control or wanting to use a different language for their
applications.

The only non-backwards compatible change compared to previous versions
is the removal of queries on lists and maps in the HTTP JSON API. There
is no trivial migration for this. If you were relying on these
capabilities please get in touch with us via [email protected] or on
Slack. We'd like to hear how you were making use of the feature so that
we can replace it with something better, and we will make some
suggestions to work around the removal.

Improved Time Model

Background

SDK Release 0.13.55 introduced a new method for command deduplication
and deprecated the command field maximum_record_time. SDK Release 1.0
further improves the Ledger Time model so that users no longer need to
pass in any time related information to the Ledger API. The new time
model is designed to work under almost all circumstances without user
intervention, making developing applications against DAML Ledgers easier
in practice.

Specific Changes

• The Sandbox no longer emits Checkpoints at regular intervals in wall
  clock mode.
• The ledger_effective_time and maximum_record_time fields have
  been removed from the Ledger API, and corresponding fields have been
  removed from the  HTTP JSON API and Ledger API language bindings.
• The --default-ttl command line argument of the HTTP JSON API is
  gone.
• Ledger Time is no longer strictly monotonically increasing, but only
  follows causal monotonicity: Ledger Time of transactions is greater
  than or equal to the Ledger Time of any input contract.
• The Command Service is no longer idempotent with respect to
  duplicate submissions. Duplicate submissions now instead return an
  ALREADY_EXISTS error, consistent with the new deduplication
  mechanism of the Command Submission Service.

Impact and Migration

Old applications will continue running against new ledgers, but ledger
effective time and maximum record time set on submissions will be
ignored. As soon as the client-side language bindings or compiled gRPC
services are updated, the fields will need to be removed as they are no
longer part of the API specification.

Better TLS Support

Background

DAML Ledgers have always supported exposing the Ledger API via TLS, but
support on consuming applications was inconsistent and often required
client certificates. From this release onward, more client components
support consuming the Ledger API via TLS without client authentication.

Specific Changes

• When Sandbox is run with TLS enabled, you can now configure the
  requirement for client authentication via  --client-auth. See the
  documentation
  for more information.
• The daml deploy and daml ledger commands now support connecting
  to the Ledger API via TLS. See their
  documentation
  for more information.
• DAML Script and DAML Triggers now support TLS by passing the --tls
  flag. You can set certificates for client authentication via --pem
  and --crt and a custom root CA for validating the server
  certificate via --cacrt.
• Navigator, DAML Script, DAML REPL, DAML Triggers, and Extractor can
  now run against a TLS-enabled ledger without client authentication.
  You can enable TLS without any special certificates by passing
  --tls.
• DAML Script and DAML Triggers have the option to configure
  certificates for client authentication via --pem and --crt and a
  custom root CA for validating the server certificate via --cacrt.

Impact and Migration

This is a new capability, so no action is needed. These new features are
useful in production environments where client to ledger connections may
need to be secured.

Next Generation Sandbox

Background

The DAML Sandbox has had a major architectural overhaul to bring it and
its user experience even closer in line with other DAML Ledgers. The new
Sandbox is now the default, but the "classic" Sandbox is included as a
deprecated version in this release. The classic Sandbox will be removed
from the SDK in a future release and will not be actively developed
further.

Specific Changes

• daml sandbox and daml start start the new Sandbox. The classic
  sandbox can be invoked via daml sandbox-classic and
  daml start --sandbox-classic.
• Wall Clock Time mode (--wall-clock-time) is now the default.
• Scenarios are no longer supported for ledger initialization.
• Contract identifiers are hashes instead of longer sequence numbers.
  • A new static contract identifier seeding scheme has been added
    to enable reproducible contract identifiers in combination with
    --static-time. Set flag --contract-id-seeding=static to use
    it.
• Ledger API Offsets are no longer guaranteed to be a parsable number.
  They are an opaque string that can be compared lexicographically.
• The command line flags --auth-jwt-ec256-crt and
  --auth-jwt-ec512-crt were renamed to --auth-jwt-es256-crt and
  --auth-jwt-es512-crt, respectively, to align them with the
  cryptographic algorithms used.

Impact and Migration

The impact is primarily on demo applications running in static time mode
and/or using scenarios for ledger initialization. Since both the
classic  and new Sandbox are compliant DAML Ledgers, there is no
difference in behavior apart from these fringes.

If you rely on static time mode, set it explicitly using
--static-time.

• If you rely on reproducible contract ident...

v0.13.56-snapshot.20200411.3905.0.f050da78

Used `daml codegen java` instead of calling the codegen from maven (#…

v0.13.56-snapshot.20200408.3877.0.1ddcd3c0

Add a note that vscode needs to be restarted (#5503)

changelog_begin
changelog_end

v0.13.56-snapshot.20200408.3871.0.b3ccacc0

DAML-LF. fix computation of cid (#5486)

The fix is to use the number of nodes of the partial transaction instead of the number of nodes of the full transaction.


CHANGELOG_BEGIN
CHANGELOG_END

v0.13.56-snapshot.20200407.3859.0.b488b353

Fix sdk-versions in daml_build rule (#5479)

I thought we already were patching those because the versions of all
other packages are hardcoded but apparently we just got lucky so far
because we got it consistently wrong. The dependency on the trigger
and script libraries resulted in them being inconsistently wrong since
those do set the correct SDK version so things fell over.

changelog_begin
changelog_end

v0.13.56-snapshot.20200407.3843.0.10bac143

kvutils: Simplify calculating the weight of a Caffeine cache. (#5461)

* kvutils: Simplify calculating the weight of a Caffeine cache.

And remove an errant `println` that slipped through the cracks.

Thank you to @ben-manes for the tip!

CHANGELOG_BEGIN
CHANGELOG_END

* kvutils: Make classes final and defs into vals.

Co-Authored-By: Stefano Baghino <[email protected]>

Co-authored-by: Stefano Baghino <[email protected]>