Given we both got our laptops out just after take-off, and had code on our screens, it was pretty clear we were heading to Cancún, and started talking about our projects with one another. I’d see Nick talk about ENS at the London Ethereum Meetup a while back, and had integration with it in web3j on my todo list. However, given that I had Nick sat next to me, and a 9 hour flight in front of me, it was a no-brainer to start work on it then and there!
The ENS support in web3j means that anywhere you previously had to use a contract or wallet address, you can now use an ENS domain name instead.
I.e. For your smart contracts you can use:
YourSmartContract contract = YourSmartContract.load( "<name>.ens", web3j, credentials, GAS_PRICE, GAS_LIMIT);
It’s also supported in web3j’s command line tools:
$ web3j wallet send <name>.ens
The web3j implementation provides input normalisation and validation adhering to UTS #46. Nick was adamant that any ENS implementations does this :).
web3j can now work with Truffle JSON files for generating smart contract wrappers. This means that if you currently or have used Truffle for your smart contract development, you can generate smart contract wrappers in Java from them. The advantage of this approach is that your smart contracts will know where they’ve been deployed previously.
YourSmartContract contract = YourSmartContract.load( YourSmartContract.getDeployedAddress(), web3j, credentials, GAS_PRICE, GAS_LIMIT);
Where the network id is as per EIP 155.
To generate the wrapper files, there is a new truffle argument to the web3j command line tool:
$ web3j truffle generate [--javaTypes|--solidityTypes] /path/to/.json -o /path/to/src/main/java -p com.your.organisation.name
Ezra Epstein deserves the credit for this change, as he had the idea and implemented it.
For details of other fixes with this release, please refer to the v3.1.0 release page.
Are you using web3j?