Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Optimize ClassGraph Scanning

Abierto
  • ¿Algo no está bien?
#627 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
api, backend

Línea de trabajo

Start with SerializerRegistryImpl.findAndSetContents() and RoutingRegistryImpl.findAndSetContracts(), then review their ClassGraph scan setup and the ScanResult.toJSON()/fromJSON() APIs. Determine how optional packaged metadata can be shared by both registries while preserving runtime scanning when absent. Done means startup discovers serializers, contracts, and data types without duplicate full-classpath scans when an index is present, with fallback and GraalVM Native Image limitations documented.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Current Status

The Java contract API performs two separate ClassGraph scans during startup:

  1. SerializerRegistryImpl.findAndSetContents() scans the runtime classpath for classes annotated with @Serializer.
  2. 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!

Lenguaje dominante
Java
Estrellas
322
Forks
210
Merge medio
15 h 16 min
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hyperledger/fabric-chaincode-java

Todos los issues de hyperledger/fabric-chaincode-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.