Skip to content

El Devcon 3 especial (v3.0.1)
Compare
Choose a tag to compare
@conor10 conor10 released this 30 Oct 21:35
v3.0.1
525565d

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.

Assets 6
Loading