Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Optimize ClassGraph Scanning

Ouverte
#627 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
java
Domaine
api, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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!

Langage dominant
Java
Étoiles
322
Forks
210
Merge moyen
15 h 16 min
PR mergées (30 j)
29

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de hyperledger/fabric-chaincode-java

Toutes les issues de hyperledger/fabric-chaincode-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.