0.0.105.1

This exposes the ProbabilisticScorer added in 0.0.105 which was missing in 0.0.105.0

v0.0.105.0

No significant changes to bindings themselves, see upstream release notes for 0.0.105.for changes.

v0.0.104.1

No substantial changes on the Java end, initial TypeScript support is
still in-flight.

Only substantial change is a lockorder fix backported from the
(upcoming) 0.0.105 release. See
lightningdevkit/rust-lightning#1238 for more
details.

v0.0.104.0

• Updates to LDK version 0.0.104. See
  https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.104
  for the full changelog.
• Use Reference.reachabilityFence to work around Java's somewhat
  poorly documented memory model. This seems to be the intended use so
  its likely this will fix the early finalization bugs we've seen, but
  formal documentation on the Java memory model appears to be lacking
  so its possible (albeit unlikely) that more may be required later.
  This bumps our required Java version from 1.8 to 9.
• Exposes Hash and Eq via Java's hashCode and equals.
• Thows an exception instead of incorrect operation if multiple
  ChannelMonitors for the same channel are provided to a
  ChannelManagerConstructor.

v0.0.103.1

Based on LDK v0.0.103 and LDK-C-Bindings v0.0.103.1, this fixes a number
of minor (and a few major) issues in the Java bindings.

• Exposes the full Logger interface to Java, with information on
  severity and module which originated the log call.
• Expose read on MaybeReadable objects (like Event) which may or
  may not read an object which was written (some Events are not
  written to disk).
• Include documentation from Rust on enum variants.
• Allow specifying a UserConfig object in both
  ChannelManagerConstructor constructors.
• Check array lengths for constant-length arrays (like keys and block
  headers) prior to calling into Rust. This avoids undefined behavior
  (often a crash) when a byte array of incorrect length is passed.
• Provide a new is_ok method on Result types instead of requiring
  matching of the object's type.
• Include missing functions on 3-tuples.
• Resolve a rare use-after-free when returning an object from a Java
  interface method that was called from Rust.
• Increase pointer validity checking in leaktracking builds.
• Resolve a NullPointerException when calling trait methods on a Rust
  instance of a trait which was wrapped in an Option.

v0.0.103.0

Upstream release notes at https://github.com/rust-bitcoin/rust-lightning/releases/tag/v0.0.103 changes in Java bindings are related to new upstream APIs though not insignificant.

v0.0.102.0

Java-specific changes in this release are minimal. For upstream release notes see https://github.com/rust-bitcoin/rust-lightning/releases/tag/v0.0.102

v0.0.101.3

A few minor fixes:

• Slightly faster networking (with less GC overhead), relying on some minor reflection to work around Java's overly naive package system,
• Android 11 fixes
• Bumps Android API to 24 which was required but not correctly marked

v0.0.101.2

This release fixes a number of under-the-hood bugs, but has no user-visible API changes.

• Fixes a bug where strings passed from Rust by reference to Java may cause double-frees. This is visible occasionally as Events which contain strings passed to Java handle_event methods may cause crashes.
• Tweak library paths in Android AARs to match the NDK documentation. This may fix shared library load failures on arm64 devices, though its a bit of a shot in the dark.
• Avoid introducing reference loops for non-trait objects passed to Rust when the object is cloned before being passed. Historically, the bindings generation attempted to aggressively avoid clones in order to avoid significant performance penalties. While we should move our way back there, clones ended up being added over time to fix specific edge cases. As long as the clones are present, there is no reason to add the explicit references via the ptrs_to list, which may cause effective memory leaks.

v0.0.101.1

This release rewrites our tuple handling to avoid Java generics as suggested in #27. By using more common codepaths, this cuts known memory leaks as much as half, depending on the workload. That said, because its relatively fresh mapping logic, errors may occur.

It also fixes an issue in v0.0.101.0 where constructing a NetGraphMsgHandler from serialized NetworkGraph data was not possible.