* native constructors that were meant to be called by consumers now have static equivalents
* all native constructors are discouraged from being used by a JavaDoc comment
* one constructor that wasn't meant to be used by consumers is switched to private access
* tests and tools that resemble consumers are updated to use the new API
Note: although most native constructors are now deprecated, we're not using
annotations because we're still calling them.
We were using KeyParameter as a wrapper for a byte[] containing an
AES Key and passing it around our API. This introduced an unnecessary
API dependency on Bouncy Castle. This PR adds an AesKey class
for the same purpose to replace it.
This is a breaking change, but one that should be easy to accommodate.
This change migrates from using `NetworkParameters` to `Network` for specifying the network and
also decouples from static methods in `Address` with an interface/implementation approach.
Note that there are 3 use cases for address parsing:
1. Any network is allowed - AddressParser.parseAddressAnyNetwork(String)
2. Parse for a specified network - AddressParser.parseAddress(String, Network)
3. Parse for a previously-specified (context dependent) network - AddressParser.Strict.parseAddress(String)
In most use cases, an AddressParser instance can be accessed through the Wallet,
which already knows the Network type and in this context validation for network makes
sense. This is why `Wallet` is implementing `AddressParser.Strict`
BitcoinURI allocates its own DefaultAddressParser for now, as do some other tests
and examples that don't have access to a Wallet
In the future DefaultAddressParser may be replaced by something loaded
via the ServiceLoader mechanism or other dynamically configured mechanism.
* WalletAppKit: add a constructor that takes a BitcoinNetwork
* WalletAppKit: deprecate constructors taking netParams or Context
* WalletAppKit: add an accessor for network()
* Update examples, tools, and wallettemplate to use the new constructor
This also moves Coin, Fiat, its parent Monetary and the related MonetaryFormat into the new base package.
See the provided package-info.java for details.
* Make the static field `estimatedKeyDerivationTime` private
* Refactor the calculation to a private, side-effect free function
* Replace `estimatedKeyDerivationTimeMsec()` with `initEstimatedKeyDerivationTime()`
** Don’t return a value that wasn’t unused anyway
** Make better use of CompletableFuture API
* Platform.runLater wasn’t needed because no JavaFX functions are called
* Make all public fields private and wrap with accessors
* Make `WalletAppKit` (was confusingly named `bitcoin`) field a member not a static
* Rename `bitcoin` to `walletAppKit`
* Extract abstract class `WalletApplication` from `WalletTemplate`
* `WalletTemplate` implements `loadController()` with resource names
* `MainController`: Add `scene` member and `scene()` method
* Introduce `AppDelegate` class for delegating JavaFX `Application`
* Move almost all of `Main` to `WalletTemplate`
Rationale:
* The “template” JavaFX Application main class (`Main`) is now about 30 lines of code
* `Main` class allows easy switching between TestNet and MainNet (in fact it could become a command-line argument) and other configuration changes (e.g. `preferredOutputScriptType`)
* Prepares the way for the next steps of refactoring
* OverlayController: rename init method, add rootController to params
* OverlayableStackPaneController: update to use updated initOverlay() method,
also pass this.getClass() into GuiUtils.getResource()
* GuiUtils.getResource(): replace reference to MainController.class with clazz parameter
* Main: Reduce visibility to “package” of 3 static globals
* MainController: Reduce visibility of `instance` static to “package”, initialize
addressControl by calling 2 initialization methods
* 4 other controllers: Update for OverlayController changes
* ClickableBitcoinAddress: OverlayController changes, eliminate use of Main.APP_NAME
Rationale:
* Decrease coupling
* Eliminate cross-package use of `Main` and `MainController` static globals
* Prepare for further refactoring — moving wallettemplate.controls package
to org.bitcoinj.walletfx.controls
* Extract abstract class OverlayableStackPaneController from MainController
* Rename OverlayWindowController to OverlayController (Window was misleading)
Rationale:
1. Overlay functionality is independent of MainContoller’s wallet functions
2. Increases reusability of classes in module
3. Prepares for further refactoring
Rationale:
1. Stronger typing makes code more readable and refactorable
2. Eliminates “automatic” reflection in MainController
3. Makes overlayUI field in implementing classes private
4. Is a step towards further refactoring and reusability
Move OverlayUI and other related functionality from Main (Application) class
to MainController.
Motivation:
1. This simplifies the Main class
2. The code more logically belongs in the controller
3. The code being in the controller increases reusability
4. Is a first step towards additional refactoring made possible
because MainController can subclass an abstract class and Main
can’t because it must subclass Application
