我想在我的状态中添加验证注释，以避免在验证 Corda 事务时使用样板。例如，我可能想用一个注释来注释我的状态，以防止用负数创建状态：
class MyState(@Min(0) val amount: Int): ContractState {
override val participants = listOf<AbstractParty>()
}
然后我想在合同验证期间检查这些注释，如果有任何注释被违反，则抛出异常。
Corda 是否支持在合同验证中使用现有的验证注释库？我可以提供自己的自定义验证注释吗？
【问题讨论】：
标签： corda
注释方法会使代码更清晰，尤其是在数据模型非常复杂的情况下。
现在你有两种选择
将验证器引擎作为正常依赖项嵌入到您的 cordapp 中，在这种情况下，您将向必须信任您的成员提供实现。
个人成员可以将他们选择的验证器引擎作为普通附件附加到交易中，这将使验证器类在合约验证期间在类路径上可用。在这种情况下，交易的每个交易对手都负责检查附件哈希是否列在他们之前审核过的验证者白名单中。
但是，我们想提醒您一些相关风险，如下所列。
决定论。将来，Corda 将在确定性 JVM (DJVM) 中运行合约，任何非确定性代码都将无法执行。一些可用的 JSR303 验证器实现可能依赖于非确定性代码。需要强调的是，一旦 DJVM 完全实现，现在可以工作的合约将来可能会停止工作。 R3 打算提供一个 Gradle 插件，该插件将在构建期间验证代码的确定性，这将帮助开发人员从他们的合约中消除所有非确定性库。
一些 JSR303 实现，例如来自 Hibernate 的实现，非常繁重（大约 120k 行代码）。将来，合约类将由事务范围的类加载器加载，即将从头开始重新加载类以验证每个事务。鉴于休眠验证器需要大约 20-30 秒进行自我初始化，这将成为性能瓶颈。可能需要编写 JSR 的自定义实现，重用 Hibernate 的验证器逻辑，但去掉与合约上下文无关的更高级的功能。
作为一般建议，我们鼓励您考虑将一些繁重的工作转移到流中，因为它们没有任何与 DJVM 相关的限制。
您必须为您的成员提供一种机制来审核和验证所选的验证实施。因为这现在将成为他们作为签约方的合同的一部分。如果将来发现验证器有故障，则值得围绕这种情况进行讨论。
我们非常喜欢使用 JSR303 注释进行数据模型验证的想法，我们将帮助您完成实现它的过程，所以如果您遇到任何问题，请告诉我们。
【讨论】：