Following months of development, 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.

A full rundown of all of the great new functionality is below.

blk.io is going to be at Devcon3, so please send us a message if you’d like to chat.

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 previously, 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

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.

For further details of the other changes, please refer to the releases page.