The SDK continues to support managing chaincode using the pre v2.0 lifecycle APIs, but they are now deprecated. The new v2.0 Fabric Lifecycle chaincode APIs are fully supported. Note however, that channels need to enable v2.0 capabilities to use the new lifecycle APIs. Once v2.0 capabilities are enabled the deprecated pre v2.0 APIs ( InstallProposalRequest, InstantiateProposalRequest, UpgradeProposalRequest ) can no longer be used to manage any chaincode using that channel.
The v2.0 Lifecycle can require organizations to endorse (consent) to new chaincode being run on the channel. The default is to require a majority of organizations on the channel to endorse chaincode before it can be run. For more details on Lifecycle chaincode management see the Fabric chaincode lifecycle
The End2endLifecycleIT.java integration test tests and demonstrates these APIs between two organizations.
Applications can now register handlers for both Peers and Orderers that the connection document defines to allow the applications a means to control adding any additional properties on Peers and Orderers before they are added to the channel. An example of defining a Peer handler is shown NetworkConfigTest testPeerOrdererOverrideHandlers and a handler for Orderers
Previously applications could register an event handler to get notified when any blocks were commited to a peer's ledger by getting a callback on another thread. A new handler is now available allowing applications to register a handler with a Java blocking queue that block events will be added as the SDK detects blocks are committed on a peer's ledger. Examples of registering this handler is shown in UpdateChannelIT
The SDK creates it's own threads through a Java Executor services. This change allows applications to supply their own. This is really needed except in cases of some managed environments that want to control their own thread pools.