net.corda.contracts.testing

## Class DummyDealContract.State

- net.corda.contracts.testing.DummyDealContract.State

- All Implemented Interfaces:
    ContractState, DealState, LinearState
  Enclosing class:
    DummyDealContract

      public static class DummyDealContract.State
      implements DealState

- - ### Nested Class Summary

    - ### Nested classes/interfaces inherited from interface net.corda.core.contracts.LinearState

      `LinearState.ClauseVerifier<S extends LinearState,C extends CommandData>`

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `State(Contract contract, java.util.List<? extends net.corda.core.crypto.CompositeKey> participants, UniqueIdentifier linearId, java.lang.String ref, java.util.List<net.corda.core.crypto.AnonymousParty> parties)`

  - ### Method Summary

    All Methods Instance Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `Contract` | `component1()` An instance of the contract class that will verify this state.
    `java.util.List<net.corda.core.crypto.CompositeKey>` | `component2()` A participant is any party that is able to consume this state in a valid transaction.
    `UniqueIdentifier` | `component3()` Unique id shared by all LinearState states throughout history within the vaults of all parties.
    `java.lang.String` | `component4()` Human readable well known reference
    `java.util.List<net.corda.core.crypto.AnonymousParty>` | `component5()` Exposes the Parties involved in a generic way.
    `DummyDealContract.State` | `copy(Contract contract, java.util.List<? extends net.corda.core.crypto.CompositeKey> participants, UniqueIdentifier linearId, java.lang.String ref, java.util.List<net.corda.core.crypto.AnonymousParty> parties)`
    `boolean` | `equals(java.lang.Object p)`
    `TransactionBuilder` | `generateAgreement(Party notary)` Generate a partial transaction representing an agreement (command) to this deal, allowing a general deal/agreement flow to generate the necessary transaction for potential implementations.
    `Contract` | `getContract()` An instance of the contract class that will verify this state.
    `UniqueIdentifier` | `getLinearId()` Unique id shared by all LinearState states throughout history within the vaults of all parties.
    `java.util.List<net.corda.core.crypto.CompositeKey>` | `getParticipants()` A participant is any party that is able to consume this state in a valid transaction.
    `java.util.List<net.corda.core.crypto.AnonymousParty>` | `getParties()` Exposes the Parties involved in a generic way.
    `java.lang.String` | `getRef()` Human readable well known reference
    `int` | `hashCode()`
    `boolean` | `isRelevant(java.util.Set<? extends java.security.PublicKey> ourKeys)` True if this should be tracked by our vault(s).
    `java.lang.String` | `toString()`

    - ### Methods inherited from interface net.corda.core.contracts.DealState

      `generateAgreement, getParties, getRef`

    - ### Methods inherited from interface net.corda.core.contracts.LinearState

      `getLinearId, isRelevant`

    - ### Methods inherited from interface net.corda.core.contracts.ContractState

      `getContract, getParticipants`

- - ### Constructor Detail

    - #### State

          public State(Contract contract,
                       java.util.List<? extends net.corda.core.crypto.CompositeKey> participants,
                       UniqueIdentifier linearId,
                       java.lang.String ref,
                       java.util.List<net.corda.core.crypto.AnonymousParty> parties)

      Parameters:
        `contract` -

        An instance of the contract class that will verify this state.

        # Discussion

        This field is not the final design, it's just a piece of temporary scaffolding. Once the contract sandbox is further along, this field will become a description of which attachments are acceptable for defining the contract.

        Recall that an attachment is a zip file that can be referenced from any transaction. The contents of the attachments are merged together and cannot define any overlapping files, thus for any given transaction there is a miniature file system in which each file can be precisely mapped to the defining attachment.

        Attachments may contain many things (data files, legal documents, etc) but mostly they contain JVM bytecode. The class files inside define not only `interface Contract` implementations but also the classes that define the states. Within the rest of a transaction, user-providable components are referenced by name only.

        This means that a smart contract in Corda does two things:

        1. Define the data structures that compose the ledger (the states)

        2. Define the rules for updating those structures

        The first is merely a utility role ... in theory contract code could manually parse byte streams by hand. The second is vital to the integrity of the ledger. So this field needs to be able to express constraints like:

        - Only attachment 733c350f396a727655be1363c06635ba355036bd54a5ed6e594fd0b5d05f42f6 may be used with this state.

        - Any attachment signed by public key 2d1ce0e330c52b8055258d776c40 may be used with this state.

        - Attachments (1, 2, 3) may all be used with this state.

        and so on. In this way it becomes possible for the business logic governing a state to be evolved, if the constraints are flexible enough.

        Because contract classes often also define utilities that generate relevant transactions, and because attachments cannot know their own hashes, we will have to provide various utilities to assist with obtaining the right code constraints from within the contract code itself.

        TODO: Implement the above description. See COR-226

        `participants` -

        A participant is any party that is able to consume this state in a valid transaction.

        The list of participants is required for certain types of transactions. For example, when changing the notary for this state (TransactionType.NotaryChange), every participant has to be involved and approve the transaction so that they receive the updated state, and don't end up in a situation where they can no longer use a state they possess, since someone consumed that state during the notary change process.

        The participants list should normally be derived from the contents of the state. E.g. for Cash the participants list should just contain the owner.

        `linearId` - Unique id shared by all LinearState states throughout history within the vaults of all parties.Verify methods should check that one input and one output share the id in a transaction,except at issuance/termination.
        `ref` - Human readable well known reference(e.g.trade reference)
        `parties` -

        Exposes the Parties involved in a generic way.

        Appears to duplicate participants a property of ContractState. However participants only holds public keys. Currently we need to hard code Party objects into ContractStates. `class Party` objects are a wrapper for public keys which also contain some identity information about the public key owner. You can keep track of individual parties by adding a property for each one to the state, or you can append parties to the parties list if you are implementing `interface DealState`. We need to do this as identity management in Corda is currently incomplete, therefore the only way to record identity information is in the ContractStates themselves. When identity management is completed, parties to a transaction will only record public keys in the `interface DealState` and through a separate process exchange certificates to ascertain identities. Thus decoupling identities from ContractStates.

  - ### Method Detail

    - #### isRelevant

          public boolean isRelevant(java.util.Set<? extends java.security.PublicKey> ourKeys)

      True if this should be tracked by our vault(s).

    - #### generateAgreement

          public TransactionBuilder generateAgreement(Party notary)

      Generate a partial transaction representing an agreement (command) to this deal, allowing a general deal/agreement flow to generate the necessary transaction for potential implementations.

      TODO: Currently this is the "inception" transaction but in future an offer of some description might be an input state ref

      TODO: This should more likely be a method on the Contract (on a common interface) and the changes to reference a Contract instance from a ContractState are imminent, at which point we can move this out of here.

    - #### getContract

          public Contract getContract()

      An instance of the contract class that will verify this state.

      # Discussion

      This field is not the final design, it's just a piece of temporary scaffolding. Once the contract sandbox is further along, this field will become a description of which attachments are acceptable for defining the contract.

      Recall that an attachment is a zip file that can be referenced from any transaction. The contents of the attachments are merged together and cannot define any overlapping files, thus for any given transaction there is a miniature file system in which each file can be precisely mapped to the defining attachment.

      Attachments may contain many things (data files, legal documents, etc) but mostly they contain JVM bytecode. The class files inside define not only `interface Contract` implementations but also the classes that define the states. Within the rest of a transaction, user-providable components are referenced by name only.

      This means that a smart contract in Corda does two things:

      1. Define the data structures that compose the ledger (the states)

      2. Define the rules for updating those structures

      The first is merely a utility role ... in theory contract code could manually parse byte streams by hand. The second is vital to the integrity of the ledger. So this field needs to be able to express constraints like:

      - Only attachment 733c350f396a727655be1363c06635ba355036bd54a5ed6e594fd0b5d05f42f6 may be used with this state.

      - Any attachment signed by public key 2d1ce0e330c52b8055258d776c40 may be used with this state.

      - Attachments (1, 2, 3) may all be used with this state.

      and so on. In this way it becomes possible for the business logic governing a state to be evolved, if the constraints are flexible enough.

      Because contract classes often also define utilities that generate relevant transactions, and because attachments cannot know their own hashes, we will have to provide various utilities to assist with obtaining the right code constraints from within the contract code itself.

      TODO: Implement the above description. See COR-226

      See Also:
        `interface Contract`

    - #### getParticipants

          public java.util.List<net.corda.core.crypto.CompositeKey> getParticipants()

      A participant is any party that is able to consume this state in a valid transaction.

      The list of participants is required for certain types of transactions. For example, when changing the notary for this state (TransactionType.NotaryChange), every participant has to be involved and approve the transaction so that they receive the updated state, and don't end up in a situation where they can no longer use a state they possess, since someone consumed that state during the notary change process.

      The participants list should normally be derived from the contents of the state. E.g. for Cash the participants list should just contain the owner.

      See Also:
        TransactionType.NotaryChange, Cash

    - #### getLinearId

          public UniqueIdentifier getLinearId()

      Unique id shared by all LinearState states throughout history within the vaults of all parties.

      Verify methods should check that one input and one output share the id in a transaction,except at issuance/termination.

    - #### getRef

          public java.lang.String getRef()

      Human readable well known reference

      (e.g.trade reference)

    - #### getParties

          public java.util.List<net.corda.core.crypto.AnonymousParty> getParties()

      Exposes the Parties involved in a generic way.

      Appears to duplicate participants a property of ContractState. However participants only holds public keys. Currently we need to hard code Party objects into ContractStates. `class Party` objects are a wrapper for public keys which also contain some identity information about the public key owner. You can keep track of individual parties by adding a property for each one to the state, or you can append parties to the parties list if you are implementing `interface DealState`. We need to do this as identity management in Corda is currently incomplete, therefore the only way to record identity information is in the ContractStates themselves. When identity management is completed, parties to a transaction will only record public keys in the `interface DealState` and through a separate process exchange certificates to ascertain identities. Thus decoupling identities from ContractStates.

      See Also:
        ContractState, ContractState, `class Party`, `interface DealState`, ContractState, `interface DealState`, ContractState

    - #### component1

          public Contract component1()

      An instance of the contract class that will verify this state.

      # Discussion

      This field is not the final design, it's just a piece of temporary scaffolding. Once the contract sandbox is further along, this field will become a description of which attachments are acceptable for defining the contract.

      Recall that an attachment is a zip file that can be referenced from any transaction. The contents of the attachments are merged together and cannot define any overlapping files, thus for any given transaction there is a miniature file system in which each file can be precisely mapped to the defining attachment.

      Attachments may contain many things (data files, legal documents, etc) but mostly they contain JVM bytecode. The class files inside define not only `interface Contract` implementations but also the classes that define the states. Within the rest of a transaction, user-providable components are referenced by name only.

      This means that a smart contract in Corda does two things:

      1. Define the data structures that compose the ledger (the states)

      2. Define the rules for updating those structures

      The first is merely a utility role ... in theory contract code could manually parse byte streams by hand. The second is vital to the integrity of the ledger. So this field needs to be able to express constraints like:

      - Only attachment 733c350f396a727655be1363c06635ba355036bd54a5ed6e594fd0b5d05f42f6 may be used with this state.

      - Any attachment signed by public key 2d1ce0e330c52b8055258d776c40 may be used with this state.

      - Attachments (1, 2, 3) may all be used with this state.

      and so on. In this way it becomes possible for the business logic governing a state to be evolved, if the constraints are flexible enough.

      Because contract classes often also define utilities that generate relevant transactions, and because attachments cannot know their own hashes, we will have to provide various utilities to assist with obtaining the right code constraints from within the contract code itself.

      TODO: Implement the above description. See COR-226

      See Also:
        `interface Contract`

    - #### component2

          public java.util.List<net.corda.core.crypto.CompositeKey> component2()

      A participant is any party that is able to consume this state in a valid transaction.

      The list of participants is required for certain types of transactions. For example, when changing the notary for this state (TransactionType.NotaryChange), every participant has to be involved and approve the transaction so that they receive the updated state, and don't end up in a situation where they can no longer use a state they possess, since someone consumed that state during the notary change process.

      The participants list should normally be derived from the contents of the state. E.g. for Cash the participants list should just contain the owner.

      See Also:
        TransactionType.NotaryChange, Cash

    - #### component3

          public UniqueIdentifier component3()

      Unique id shared by all LinearState states throughout history within the vaults of all parties.

      Verify methods should check that one input and one output share the id in a transaction,except at issuance/termination.

    - #### component4

          public java.lang.String component4()

      Human readable well known reference

      (e.g.trade reference)

    - #### component5

          public java.util.List<net.corda.core.crypto.AnonymousParty> component5()

      Exposes the Parties involved in a generic way.

      Appears to duplicate participants a property of ContractState. However participants only holds public keys. Currently we need to hard code Party objects into ContractStates. `class Party` objects are a wrapper for public keys which also contain some identity information about the public key owner. You can keep track of individual parties by adding a property for each one to the state, or you can append parties to the parties list if you are implementing `interface DealState`. We need to do this as identity management in Corda is currently incomplete, therefore the only way to record identity information is in the ContractStates themselves. When identity management is completed, parties to a transaction will only record public keys in the `interface DealState` and through a separate process exchange certificates to ascertain identities. Thus decoupling identities from ContractStates.

      See Also:
        ContractState, ContractState, `class Party`, `interface DealState`, ContractState, `interface DealState`, ContractState

    - #### copy

          public DummyDealContract.State copy(Contract contract,
                                              java.util.List<? extends net.corda.core.crypto.CompositeKey> participants,
                                              UniqueIdentifier linearId,
                                              java.lang.String ref,
                                              java.util.List<net.corda.core.crypto.AnonymousParty> parties)

    - #### toString

          public java.lang.String toString()

    - #### hashCode

          public int hashCode()

    - #### equals

          public boolean equals(java.lang.Object p)