Improvements included in this first iteration:
- Nullable/non-nullable!
- ObjectHandle typealias for Long
- Fixed handling for CompletableFuture<Void> (previously translated
without generics at all in some cases)
Co-authored-by: Alex Bakon <akonradi@signal.org>
The Maven publication will still contain a -javadoc jar for
consistency, but the -dokka jar is likely to have superior rendering
in practice, particularly for Kotlin-only APIs!
Rename BackupLevel::{Messages, Media} to {Free, Paid}, then add
BackupCredentialType::{Messages, Media}.
This is a breaking change for apps and the server, both because of the
new names, and because the credential attributes have changed (both
what's in a serialized credential, and what's included in the
signature).
Previously we tried to be Fast by allocating a big local frame, enough
references for all the recipients we parsed. However, that backfired
if there were so many recipients that we couldn't allocate the local
frame. Switch to using AutoLocal references, so we have a fixed
overhead.
One interesting consequence of this is that we can't build the array
of excluded recipients in one go; instead, we now use a helper
java.util.ArrayList that we push into. Fortunately, we only exposed a
List in the public interface anyway.
Failures would still have been caught in the aggregate test results;
but if we're going to print successes we should print skips and
failures too. (This was just an oversight.)
Each of these updates is required for the following update, and the
final one allows us to use 'record'.
The target SDK version is set to 33, matching the Android app.
Then, use FilterExceptions to filter out any exceptions that aren't
declared in the calling method's exception spec. Note that this isn't
perfect: Java's checks for typed exceptions prevents an *extra*
exception from being thrown this way, but it's still possible to
forget to *allow* an exception using FilterExceptions.
This is 99% a mechanical change; the interesting bit is in
gen_java_decl.py and one unusual pattern in NativeErrorsTest.java. No
exception specs were changed here.
Run tests that call native TESTING_ functions on Android. This requires
building a separate version of libsignal_jni.so with the testing functions
included. The test code is still omitted from the published artifacts.
Use the string bridging code introduced previously to provide string arrays to
client directly instead of joining and splitting. This eliminates the use of a
magic ',' character as a delimiter.
- use int instead of promoting to long
- add missing return type to fix compilation
- run auto-formatter
Also add the check that would have caught all of these to CI
Fix the behavior of CompletableFuture.thenApply so that if the applied function
throws an exception, the pending future receives the exception (instead of never
completing). Add tests.
This can give better error messages for JNI mistakes that might
otherwise crash or go unnoticed. Tested by introducing such a mistake.
(Though it's hard to do with the jni crate's safe interfaces, which is
a good thing!)
The Android Emulator always has its equivalent checks on, so the Slow
Tests are also giving us some confidence about our JNI usage.
The format hasn't changed, so we don't need to bump the version number
for the messages the server sends to recipients.
This is implemented in two places: the Rust side for round-trip
testing, and the Java side for what the server actually does. (Both
are implemented to avoid unnecessary copies and unfortunately the two
aren't conveniently compatible with one another, but it's a simple
implementation anyway.)
This takes advantage of the fact that multiple devices for the same
user will have the same identity key and therefore will use the same
per-recipient SSv2 data anyway.
This commit also enforces (on the server side) that device IDs are in
the range 1..=127 for destinations of a SSv2 message; previously they
were varint-encoded.
When send support is added, the round-trip Rust tests will
automatically start testing this as well.
For now, the "runtime" is spawning a thread that then uses
now_or_never, but eventually this will be a persistent tokio runtime
of some kind.
Also for now, this is only implemented for Java. Swift and Node
support coming soon.
