_ Git - ldk-java/blob - README.md

   1 LDK Java, C#, and TypeScript Bindings
   2 =====================================
   3
   4 This repo contains an autogeneration system to generate LDK bindings for garbage-collected languages, currently including Java, C#, and TypeScript. See below for the current status of the bindings.
   5
   6 The auto-generated code contains copies of the Rust documentation, which can also be viewed at
   7 [docs.rs/lightning](https://docs.rs/lightning). High-level documentation of the API can be found at
   8 [lightningdevkit.org](https://lightningdevkit.org).
   9
  10 API Mappings
  11 ============
  12
  13 As the bindings are auto-generated, they often read fairly verbose with lots of additional type
  14 information compared to what might be expected with a native interface. A brief understanding of
  15 some Rust nomenclature will help read bindings:
  16
  17 ## `Result`
  18
  19 Rust APIs make heavy use of the `Result` enum. They can either be in an `Ok` state, with an
  20 optional value or an `Err` state, with an optional error value. These often appear as
  21 `Result_OKValueTypeErrValueTypeZ` in bindings. Subclasses are build for the `Ok` and `Err` states,
  22 with the appropriate values available in the subclasses which all instances will be of.
  23
  24 ## `Option`
  25
  26 Similar to `Result`, Rust APIs make heavy use of the `Option` enum. Like `Result`, they may contain
  27 a value in the `Some` state, but may contain no value in the `None` state. They are mapped
  28 similarly to `Result`s, usually as `Option_SomeValueTypeZ`.
  29
  30 ## Tuples
  31
  32 Rust APIs occasionally use tuples, which are simply mapped as a tuple type like
  33 `TwoTuple_FirstValueTypeSecondValueTypeZ`. Individual elements can be fetched or set with `get_a()`,
  34 `get_b()`, `set_a(..)`, etc.
  35
  36 ## Tuple Types
  37
  38 Rust APIs occasionally build structs which are simply a named tuple type. These appear in rust as,
  39 eg, `struct PrintableString(String)`, and in the bindings as simply the class name (eg
  40 `class PrintableString`). The value(s) in the tuple can be fetched or set with `get_a()`,
  41 `get_b()`, `set_a(..)`, etc.
  42
  43 Building
  44 ========
  45
  46 The releases for Java, C#, and TypeScript are all deterministic. You should be able to reproduce
  47 the release binaries identically by running the scripts run in CI, see
  48 [.github/workflows/build.yml](.github/workflows/build.yml).
  49
  50 Releases for all platforma re built on Linux as that is the easiest way to get things
  51 deterministic, however building on macOS should also work. Building on Windows is not currently
  52 supported.
  53
  54 Status
  55 ======
  56
  57 ## Java
  58
  59 The Java bindings are relatively mature, and should be considered safe for production use. Still,
  60 as they have relatively few users, unexpected issues remain possible, and bug reports are welcome.
  61
  62 ## TypeScript
  63
  64 The TypeScript bindings are functionally complete, but should be considered beta quality. As there
  65 are relatively few users, unexpected issues remain likely, and bug reports are welcome.
  66
  67 The TypeScript bindings require modern web standards, including support for `FinalizationRegistry`
  68 and `WeakRef` (Chrome 84, Firefox 79, Safari 14.1/iOS 14.5 and Node 14.6) and WASM BigInt support
  69 (Chrome 85, Firefox 78, Safari 14.1/iOS 14.5, and Node 15.0).
  70
  71 For users of Node.JS environments you may wish to use the `lightningdevkit-node-net` package as
  72 well to implement the required network handling to bridge the `lightningdevkit` package's
  73 `SocketDescriptor` interface to Node.JS TCP Sockets. For those wishing to run a lightning node in
  74 the browser you will need to provide your own bridge from `SocketDescriptor` to a WebSocket proxy.
  75
  76 # C#
  77
  78 The C# bindings are functionally complete, but should be considered beta quality. As they are
  79 relatively new, unexpected issues remain possible, and bug reports are welcome.
  80
  81 ## General
  82
  83 The only known issue resulting in a use-after-free bug requires custom a custom ChannelKeys instance
  84 created as a part of a new channel. After the channel is created, the ChannelKeys object will not
  85 be freed while the parent ChannelManager exists, however if the ChannelManager is garbage collected
  86 while a ChannelMonitor object which is associated with the same channel exists, a use-after-free bug
  87 may occur. This issue should be relatively rare as uses where a ChannelManager is removed while
  88 associated ChannelMonitors exist is not anticipated.