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.

v0.0.101.0

Upstream release notes:

API Updates

• Custom message types are now supported directly in the PeerManager,
  allowing you to send and receive messages of any type that is not natively
  understood by LDK. This requires a new type bound on PeerManager, a
  CustomMessageHandler. IgnoringMessageHandler provides a simple default
  for this new bound for ignoring unknown messages (#1031, #1074).
• Route graph updates as a result of failed payments are no longer provided as
  MessageSendEvent::PaymentFailureNetworkUpdate but instead included in a
  new field in the Event::PaymentFailed events. Generally, this means route
  graph updates are no longer handled as a part of the PeerManager but
  instead through the new EventHandler implementation for
  NetGraphMsgHandler. To make this easy, a new parameter to
  lightning-background-processor::BackgroundProcessor::start is added, which
  contains an Optional NetGraphmsgHandler. If provided as Some, relevant
  events will be processed by the NetGraphMsgHandler prior to normal event
  handling (#1043).
• NetworkGraph is now, itself, thread-safe. Accordingly, most functions now
  take &self instead of &mut self and the graph data can be accessed
  through NetworkGraph.read_only (#1043).
• The balances available on-chain to claim after a channel has been closed are
  now exposed via ChannelMonitor::get_claimable_balances and
  ChainMonitor::get_claimable_balances. The second can be used to get
  information about all closed channels which still have on-chain balances
  associated with them. See enum variants of ln::channelmonitor::Balance and
  method documentation for the above methods for more information on the types
  of balances exposed (#1034).
• When one HTLC of a multi-path payment fails, the new field all_paths_failed
  in Event::PaymentFailed is set to false. This implies that the payment
  has not failed, but only one part. Payment resolution is only indicated by an
  Event::PaymentSent event or an Event::PaymentFailed with
  all_paths_failed set to true, which is also set for the last remaining
  part of a multi-path payment (#1053).
• To better capture the context described above, Event::PaymentFailed has
  been renamed to Event::PaymentPathFailed (#1084).
• A new event, ChannelClosed, is provided by ChannelManager when a channel
  is closed, including a reason and error message (if relevant, #997).
• lightning-invoice now considers invoices with sub-millisatoshi precision
  to be invalid, and requires millisatoshi values during construction (thus
  you must call amount_milli_satoshis instead of amount_pico_btc, #1057).
• The BaseSign interface now includes two new hooks which provide additional
  information about commitment transaction signatures and revocation secrets
  provided by our counterparty, allowing additional verification (#1039).
• The BaseSign interface now includes additional information for cooperative
  close transactions, making it easier for a signer to verify requests (#1064).
• Route has two additional helper methods to get fees and amounts (#1063).
• Txid and Transaction objects can now be deserialized from responses when
  using the HTTP client in the lightning-block-sync crate (#1037, #1061).

Bug Fixes

• Fix a panic when reading a lightning invoice with a non-recoverable
  signature. Further, restrict lightning invoice parsing to require payment
  secrets and better handle a few edge cases as required by BOLT 11 (#1057).
• Fix a panic when receiving multiple messages (such as HTLC fulfill messages)
  after a call to chain::Watch::update_channel returned
  Err(ChannelMonitorUpdateErr::TemporaryFailure) with no
  ChannelManager::channel_monitor_updated call in between (#1066).
• For multi-path payments, Event::PaymentSent is no longer generated
  multiple times, once for each independent part (#1053).
• Multi-hop route hints in invoices are now considered in the default router
  provided via get_route (#1040).
• The time peers have to respond to pings has been increased when building
  with debug assertions enabled. This avoids peer disconnections on slow hosts
  when running in debug mode (#1051).
• The timeout for the first byte of a response for requests from the
  lightning-block-sync crate has been increased to 300 seconds to better
  handle the long hangs in Bitcoin Core when it syncs to disk (#1090).

Serialization Compatibility

• Due to a bug in 0.0.100, Events written by 0.0.101 which are of a type not
  understood by 0.0.100 may lead to Err(DecodeError::InvalidValue) or corrupt
  deserialized objects in 0.100. Such Events will lead to an
  Err(DecodeError::InvalidValue) in versions prior to 0.0.100. The only such
  new event written by 0.0.101 is Event::ChannelClosed (#1087).
• Payments that were initiated in versions prior to 0.0.101 may still
  generate duplicate PaymentSent Events or may have spurious values for
  Event::PaymentPathFailed::all_paths_failed (#1053).
• The return values of ChannelMonitor::get_claimable_balances (and, thus,
  ChainMonitor::get_claimable_balances) may be spurious for channels where
  the spend of the funding transaction appeared on chain while running a
  version prior to 0.0.101. Balance information should only be relied upon
  for channels that were closed while running 0.0.101+ (#1034).
• Payments failed while running versions prior to 0.0.101 will never have a
  Some for the network_update field (#1043).

In total, this release features 67 files changed, 4980 insertions, 1888
deletions in 89 commits from 12 authors, in alphabetical order:

• Antoine Riard
• Devrandom
• Galder Zamarreño
• Giles Cope
• Jeffrey Czyz
• Joseph Goulden
• Matt Corallo
• Sergi Delgado Segura
• Tibo-lg
• Valentine Wallace
• abhik-99
• vss96

v0.0.100.1

Only change from v0.0.100.0 is a fix for Rust Zero-Sized-Types always being null when created from Java. This specifically appeared for the IgnoringMessageHandler.

v0.0.100.0

v0.0.100.0