Java Binding 0.4 and 0.5 Released
We recently released a set of upgrades that improve functionality and offer new features for Java developers building on Exonum. These upgrades (Java binding versions 0.4 and 0.5) can be found on Github here under the corresponding version tags.
New Features of Java Binding 0.4
In the 0.4 version of Exonum Java Binding, you can now interact with the Exonum core schema. Generally, the core schema is an abstraction that enables services to interact with a blockchain by accessing the data stored by the Exonum Core. This data can include transaction messages, transaction execution results, information in the blocks, node configuration, etc.
The ability to create Java interfaces for these interactions with the core schema, named “Blockchain” in our Java Binding documentation, became possible when we introduced the platform-independent Protobuf data serialization format into Exonum. This enabled us to simplify the implementation of the business logic used by any Exonum services written in Java. This also allows for additional functionality that could be used in service APIs. You can learn more about the “Blockchain” interface and its possibilities in our Java documentation.
The 0.4 Java binding release also laid the groundwork for a new “event handling” function requested by the community. Event handling means that services may subscribe to events on the blockchain and perform some operation depending on the event results. This release addresses the block commit event and implements an `after_commit` handler for it. The handler does not change the state of the blockchain but allows users to inspect it based on the service context.
In practice, the event handler functionally enables nodes to check the specific conditions upon the commitment of each new block and, for example, create corresponding transactions and push them into the queue for broadcast to the network. In this way, for instance, auditors can share amongst each other that there are no suspicious transactions in the block and that they bear the same blockchain state after each block commit.
Another 0.4 highlight is the ability to sign transactions with service keys, which is easily used in combination with the “event handling” capability described above. This feature allows nodes to create transactions and sign them with the service keys of the nodes. These transactions are generated automatically upon occurrence of some conditions. As we have already indicated above, the `after_commit` handler is just the way to check these conditions. It is not, however, obligatory to use these features together.
It is important to note that invoking this code on several or all nodes in the network unconditionally means that several transactions will be created with the same payload, but with different authors’ public keys and signatures. Therefore, the service should incorporate some business logic responsible for dealing with such transactions. In summary: the service code should know how to identify transactions with the same payload, created by different nodes, and how to process them. At the same time, if the code is used by one node only, it may become a single point of failure for the network.
New Features of Java Binding 0.5
The 0.5 release of Java Binding added another built-in Exonum service into the array of services that can be easily launched with your Exonum blockchain in Java — the Time Oracle. The Time Oracle allows user services to access the calendar time that validators supply to the blockchain. We built this blockchain service because of high demand from the community for this functionality. Our Time Oracle rivals a Swiss watch in security and reliability when building time-related services on top of Exonum. This is because it is built in the same way as the Exonum consensus algorithm; the algorithm used by the Time Oracle can tolerate up to a third of Byzantine validators. For more information on the Time Oracle, see our documentation.
Like other built-in services available in Exonum, Time Oracle may be introduced into your project by simply including it as a dependency in the configuration file of the Java Binding Applications directory.
The full list of updates, changes and fixes is available in the release changelog on GitHub. And for those who have already tried developing Java services on Exonum, we also suggest consulting the migration guide to upgrade their services to the current framework state.
Our team will be glad to share knowledge on the issues related to Exonum and/or Java Binding through our Gitter channels.
A note: The new features listed here are based on Exonum Core 0.10, meaning all releases of Java Binding also support the unified message format previously implemented in Exonum core. Both Exonum Java and Java Script Light clients remain compatible with any Exonum service written either in Rust or in Java.
