Current Status
The Java contract API performs two separate ClassGraph scans during startup:
SerializerRegistryImpl.findAndSetContents() scans the runtime classpath for classes annotated with @Serializer.RoutingRegistryImpl.findAndSetContracts() scans the runtime classpath for classes annotated with @Contract and @DataType.
Both scans use new ClassGraph().enableClassInfo().enableAnnotationInfo().scan(). For chaincodes with many dependencies, scanning the full classpath can increase startup time. This work is repeated whenever the chaincode starts, including when a peer restarts and launches its chaincode again.
ClassGraph provides ScanResult.toJSON() and ScanResult.fromJSON(String) APIs that may allow scan metadata to be generated during the build and reused at runtime.
Expected
Chaincode startup should be able to discover serializers, contracts, and data types from pre-generated scan metadata rather than scanning the full runtime classpath each time.
The change should preserve existing behavior for users who do not provide generated metadata. It should also document any limitations or additional requirements for using this approach with GraalVM Native Image, where dynamic class loading and reflection may require build-time configuration.
Solution
Add an optional build-time scan-index mechanism that packages ClassGraph metadata with the chaincode. At runtime, the shim should load that metadata and share the resulting scan information between SerializerRegistryImpl and RoutingRegistryImpl, avoiding duplicate full-classpath scans.
When no index is available, the shim should fall back to the current runtime scanning behavior. The implementation could use ClassGraph's ScanResult.toJSON() and ScanResult.fromJSON(String) APIs, or another generated-index approach, while ensuring discovered classes can still be loaded and instantiated. Any extra GraalVM Native Image configuration needed for those classes should be documented.
Please let us know if you plan to work on this.
Yes!
Current Status
The Java contract API performs two separate ClassGraph scans during startup:
SerializerRegistryImpl.findAndSetContents()scans the runtime classpath for classes annotated with@Serializer.RoutingRegistryImpl.findAndSetContracts()scans the runtime classpath for classes annotated with@Contractand@DataType.Both scans use
new ClassGraph().enableClassInfo().enableAnnotationInfo().scan(). For chaincodes with many dependencies, scanning the full classpath can increase startup time. This work is repeated whenever the chaincode starts, including when a peer restarts and launches its chaincode again.ClassGraph provides
ScanResult.toJSON()andScanResult.fromJSON(String)APIs that may allow scan metadata to be generated during the build and reused at runtime.Expected
Chaincode startup should be able to discover serializers, contracts, and data types from pre-generated scan metadata rather than scanning the full runtime classpath each time.
The change should preserve existing behavior for users who do not provide generated metadata. It should also document any limitations or additional requirements for using this approach with GraalVM Native Image, where dynamic class loading and reflection may require build-time configuration.
Solution
Add an optional build-time scan-index mechanism that packages ClassGraph metadata with the chaincode. At runtime, the shim should load that metadata and share the resulting scan information between
SerializerRegistryImplandRoutingRegistryImpl, avoiding duplicate full-classpath scans.When no index is available, the shim should fall back to the current runtime scanning behavior. The implementation could use ClassGraph's
ScanResult.toJSON()andScanResult.fromJSON(String)APIs, or another generated-index approach, while ensuring discovered classes can still be loaded and instantiated. Any extra GraalVM Native Image configuration needed for those classes should be documented.Please let us know if you plan to work on this.
Yes!