* Bump gradle wrapper to version 5.6.4
* Add distributionSha256Sum to gradle-wrapper.properties
Gradle will self-verify the sha of the downloaded wrapper
zip upon its first download.
The controlsfx is a huge JavaFX components library (0.83MB as JAR).
Turns out, we only use a single component, the PopOver. Fortunately,
the PopOver is self-contained and easy to pull out from controlsfx.
This commit embeds the PopOver in the project and removes controlsfx
dependency. The embedded version is exactly the same as previously
used in the project, so no change in semantics should occur.
The reactfx was a 0.33MB dependency / 238 Java source files.
We only used it for FxTimer helper and to measure FPS in development mode.
The small FxTimer class got copied over into the project,
so there is no change in semantics.
The FPS measurement got replaced w/ com.sun.javafx.perf.PerformanceTracker,
an internal but long stable part of JavaFx. This is probably not a problem,
because it only concerns a rarely used, developer feature.
Protobuf got updated to the latest released version 3.9.1.
The main motivation was to fix the following annoying warnings:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil (file:/home/qertoip/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.5.1/8c3492f7662fa1cbf8ca76a0f5eb1146f7725acd/protobuf-java-3.5.1.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Additionally, protobuf-gradle-plugin got updated to 0.8.10.
If a seednode is using netwlayer version 0.6.2 (or 0.6.1) it is not
reachable from other nodes. Still unclear what causes that and if it
would affect also normal Bisq nodes, but to be careful we revert to
latest stable netlayer version which fixes the issue.
We used checkpoint files from BitcoinJ 0.14.4 and those caused a very
slow initial download. I tested with the WalletAppKit and different
release version sof BitcoinJ and could reproduce the behaviour there.
WIth v0.14.5 it was much better. But also that caused slow startup in
Bisq. After creating a current checkpoint file and using that the
download is now very fast.
Also added logging for versions of BitcoinJ and libDohJ so that we have
better control which version is used.
