Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

DataType nested class

未关闭
  • 哪里不对？
#626 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
75/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
java
领域
api, backend

调研方向

Start with TypeRegistryImpl.addDataType, TypeSchema.typeConvert/updateSchemaForClass, and JSONTransactionSerializer.createComponentInstance to trace how nested class names are registered and resolved. Reproduce the issue with the provided Outer.Inner contract and verify that schema generation and deserialization use the same reference key, with no missing registry definition.

由索引模型根据 Issue 内容生成。

描述

bug
Description

The Java contract API appears to use inconsistent names for nested @DataType classes when creating schema references and registering types.

TypeRegistryImpl.addDataType(Class<?>) registers a data type using DataTypeDefinitionImpl.getSimpleName(). For a nested class such as Outer.Inner, Class.getSimpleName() returns Inner, so the registry key is Inner.

However, TypeSchema.typeConvert(Class<?>) uses Class.getTypeName() and passes that name to updateSchemaForClass(...). For Outer.Inner, the class name contains Outer$Inner. In TypeSchema.updateSchemaForClass(...), this line:

schema.put("$ref", "#/components/schemas/" + className.substring(className.lastIndexOf('.') + 1));

produces:

#/components/schemas/Outer$Inner

instead of:

#/components/schemas/Inner

This creates a registry lookup mismatch. During deserialization, the schema reference resolves to Outer$Inner, but the type registry contains the data type under Inner. The lookup returns null, and JSONTransactionSerializer.createComponentInstance(...) then throws a NullPointerException when it tries to use the missing definition.

The reference mismatch can also be observed directly by calling TypeSchema.typeConvert(Outer.Inner.class) from a smart contract: its "$ref" is #/components/schemas/Outer$Inner, while the registry uses the key Inner.

Steps to reproduce

  1. Define a nested @DataType class:

    public class Outer {
    @DataType
    public static class Inner {
        @Property
        private String value;

        public Inner() {
        }
    }
}

  2. Define a contract transaction that accepts the nested data type:

    @Contract(name = "NestedTypeContract")
public class NestedTypeContract implements ContractInterface {
    @Transaction
    public Outer.Inner echo(final Context context, final Outer.Inner input) {
        return input;
    }

    @Transaction
    public String inspectSchema(final Context context) {
        return TypeSchema.typeConvert(Outer.Inner.class).getRef();
    }
}

  3. Start the contract so the shim scans the @DataType class. The type registry registers Outer.Inner under its simple name:

    Inner

  4. Invoke inspectSchema. Observe that TypeSchema.typeConvert(Outer.Inner.class).getRef() returns:

    #/components/schemas/Outer$Inner

    This differs from the registry key, Inner.

  5. Submit the echo transaction with a JSON argument representing Outer.Inner:

    {"value":"test"}

  6. Observe that deserialization attempts to look up Outer$Inner in the type registry, gets null, and fails with a NullPointerException in JSONTransactionSerializer.createComponentInstance().

主要语言
Java
星标
322
派生
210
平均合并
15 小时 16 分钟
30 天内合并 PR
29

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

hyperledger/fabric-chaincode-java 的其他 Issue

查看 hyperledger/fabric-chaincode-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。