El Devcon 3 especial (v3.0.1)

Following months of development, just in time for Devcon 3 the web3j 3.0 milestone release has dropped. This release provides numerous enhancements aimed at making it even easier to work with Ethereum and smart contracts in JVM languages.

Modular

web3j is now a modular project. For each web3j release, a number of artifacts are published:

• utils - Minimal set of utility classes
• rlp - Recursive Length Prefix (RLP) encoders
• abi - Application Binary Interface (ABI) encoders
• core - Much like the previous web3j core artifact without the code generators
• crypto - Ethereum crypto libraries
• geth - Geth specific JSON-RPC module
• parity - Parity specific JSON-RPC module
• tuples - Simple tuples library
• codegen - code generators
• infura - Infura specific HTTP header support

The motivation here is to give developers (especially Android) more choice on which parts of the library they wish to use. My hope is also that this will encourage standardisation and reuse throughout the Ethereum ecosystem for those developers building on the JVM, so that these libraries are not being reimplemented time and time again in different projects.

For almost all use cases, if you were using web3j core previously you shouldn't have any problems dropping in the 3.0 core. Behind the scenes, there's been some refactoring, but much of the same functionality is there. You will need to regenerate your smart contract wrappers to use this release.

Native Java types in smart contract wrappers

web3j's smart contract wrappers now use native Java types by default. This means that the following Java to Solidity type conversions take place behind the scenes for you:

boolean -> bool
BigInteger -> uint/int
byte[] -> bytes
String -> string and address types
List<> -> dynamic/static array

This significantly reduces the amount of code you write, but still offers the same protection with native Solidity types in Java behind the scenes.

Updated API for remote calls

web3j previously provided async methods on its smart contract wrappers that returned a future. A new RemoteCall type is now returned, which makes it easy to choose if you want to make a remote call to an Ethereum client synchronously, asynchronously (via a CompletableFuture in Java, or Future in Android), or an Observable.

As mentioned previoysly, this does mean that you'll need to regenerate your smart contract wrappers to use web3j 3.0, but the upside is that you have a much cleaner API, and can take advantage of the numerous smart contract wrapper enhancements that came with the 3.0 release.

Migration to OkHttp

web3j now uses the excellent OkHttp library for all HTTP communication.

Parity and Geth JSON-RPC support

All of the Geth and Parity specific personal module calls are now available in web3j. Additionally web3j also supports the Parity trace module.

Thanks to @iikirilov for submitting this change.

Tuples for multiple return values in smart contracts

web3j now provides a simple Tuple type which is used by its smart contract wrappers that return multiple values. Previously this was done with lists which required casting to the correct type if there were different types returned by the method.

Transaction receipt processors

web3j provides an abstraction layer for working with Ethereum transactions whereby when you submit a transaction to the network, it continually polls your Ethereum node for a transaction receipt passing this back to the caller once one is available, indicating the transaction has been mined and placed into a block on the network.

With the 3.0 release you are able to modify how web3j polls for transactions. The default behaviour still remains the same. However, should you want to have lots of transactions in flight, web3j provides a queue that can be used to poll for those transactions, reducing the number of threads being created by the library.

You can read more here.

Transaction signing via third parties

The transaction signing logic has been refactored allowing the signing of transactions via third parties (previously it had to be performed in web3j). This means that if you want to call out to an HSM or wallet from web3j you can.

Thanks to @eztierney for submitting this change.

Documentation updates

All web3j documentation has been updated to reflect the changes to the library. If you find a broken link, or any discrepancies, please raise an issue, or better yet create a PR :) with details of what's wrong. I want to keep the standard of documentation for the library high (having invested heavily in it), so any feedback is gratefully received.

Other changes

• Removed Scrypt dependency (#165) by @dmitrychaban
• Support for providing custom headers in the HttpService (#200) by @mawenpeng
• Potential SecureRandom vulnerability on Android (#146) highlighted @ligi
• Better static arrays support (#183) by @jaycarey
• Restrict historical filters to LogFilter (#154) by @the-wastl
• Increment id field on requests (#210) by @IgorPerikov
• Allow range observables to emit one value (#184) by @iikirilov
• Removing the duplicated calls for installing and uninstalling the filter (#212) by @mochalovv
• Smart contract wrappers only require the specification of the Ether parameter if the associated methods contain the payable modifier (previously a zero value had to be provided regardless)
• Chain Id's have been brought in line with the EIP-155 specification
• Transaction utility methods have been added for generating transaction hashes

Please accept my apologies if I've missed your contribution of the list - pull requests and issues are one of the main mechanisms to get feedback from users on the library, so I appreciate people taking the time to submit them.

El Devcon 3 especial (v3.0.0-android)

See v3.0.0 for release notes.

v2.3.1

This release fixes NullPointerException after transactionObservable().subscribe
(#152).

v2.3.0

This release contains a number of fixes and enhancements to web3j.

Enhancements:

• Support event filters from block 0/earliest enhancement (#100)
• Optionally provide raw JSON-RPC response in Response objects (#111)
• Support payable functions in wrapper generator (#138)
• Network IDs for Rinkeby and Kovan (#116)

Bug fixes:

• Leading Zeros of Function Code Removed in Transaction (#104)
• When toAddress is 0x00211e7e624178e5bc57f9d1e6115ad65f3e76b8, raw transaction broadcast fails (#112)
• RLP Problem with small lists (#124)
• geth response "input string too short for address" when call sendTransaction (#127)
• JsonMappingException fix when compiling a solidity contract with eth_compileSolidity (#128)
• Dirty read in "FastRawTransactionManager", variable should be defined volatile (#128)

v2.2.2

Minor release to address handling of empty (0x) responses from ethCall (#98).

v2.2.1

Minor update that fixes an issue with the isValid() call on contract wrappers which were returning false for bytecode that contained multiple embedded contracts.

v2.2.0 A historical perspective

Observable API enhcements

This release provides a number of enhancements to web3j's Observable API. You can now request historical ranges of blocks from the blockchain on demand.

To replay a range of blocks from the blockchain:

Subscription subscription = web3j.replayBlocksObservable(
        <startBlockNumber>, <endBlockNumber>, <fullTxObjects>)
        .subscribe(block -> {
                 ...
});

To replay the individual transactions contained within a range of blocks:

Subscription subscription = web3j.replayTransactionsObservable(
        <startBlockNumber>, <endBlockNumber>)
        .subscribe(tx -> {
                 ...
});

You can also get web3j to replay all blocks up to the most current, and provide notification
(via the submitted Observable) once you've caught up:

Subscription subscription = web3j.catchUpToLatestBlockObservable(
        <startBlockNumber>, <fullTxObjects>, <onCompleteObservable>)
        .subscribe(block -> {
                 ...
});

Or, if you'd rather replay all blocks to the most current, then be notified of new subsequent
blocks being created:

Subscription subscription = web3j.catchUpToLatestAndSubscribeToNewBlocksObservable(
        <startBlockNumber>, <fullTxObjects>)
        .subscribe(block -> {
                 ...
});

I was able to replay the entire Ropsten blockchain ex. transactions (941667 blocks) in 7m22s. All transactions from Ropsten could be replayed in 41m16s on a 2013 Macbook Pro. Just make sure you use IPC to connect to your Ethereum node.

Smart contract wrapper event Observables also now provide startBlock and endBlockParameters, so you can specify the range with which you want the log or event filters to cover.

For further information refer to the filters documentation.

Smart contract verification

Smart contract wrappers now include an isValid() method to verify that the deployed bytecode at the smart contract's address matches that of the smart contract wrapper.

Long parameter values added to Solidity integer types

All of the Uint and Int Solidity types now support construction with long values, instead of only BigIntegers as was previously the case. DefaultBlockParameterNumber's also now accept long values.

Async changes

Behind the scenes in the smart contract wrappers, web3j now performs synchronous requests with Ethereum clients. This is to reduce the overhead that CompletableFutures were placing on the JVM thread pool. Completable futures are now only used in the client API for smart contract wrappers.

Other issues/pull requests

• msg.sender not set properly in contract function call (#89)
• Expose SolidityFunctionWrapperGenerator Method for other libaries (#86)
• Add initial value documentation (#73)
• Fix problems around size validation of large uint values (#71)
• Calls on contract hang after event subscription (#69)
• Sign.signedMessageToKey() can't be called because the Sign.SignatureData class is not public. (#64)
• Java smart contract wrappers does not support ABI with type of "address[] storage" (#63)
• Nonce calculated without counting pendig tx (#54)

Faster contract deployment (v2.1.0-android)

See v2.1.0 for release notes.

Faster contract deployment (v2.1.0)

Configurable polling intervals on contract deployment

The main purpose of this release is to enable users to configure the polling frequency on new smart contract deployments. Previously this was not possible, which meant that web3j-quorum users had to wait 15 seconds before their contracts could be deployed.

TransactionReceipts on contract deployment

It is now possible to obtain the TransactionReceipt associated with a contract deployment via <contract>.getTransactionReceipt(). This is only set when you call a <contract>.deploy(...) method, it will not be present on *<contract>.load(...)* methods, as no transaction takes place behind the scenes.

TransactionManager from addresses

TransactionManagers now contain a getFromAddress() method to provide the sender address associated with the TransactionManager. Thanks to androlo for the suggestion.

v2.0.2

This release addresses #59 Contract deployments failing with ClientTransactionManager.