As a PDS developer, I want static mutable utility singletons converted to instance-based classes so that parallel label validation becomes possible

[jordanpadams]

Checked for duplicates

Yes - I've already checked

🧑‍🔬 User Persona(s)

Data Engineer, PDS Developer

💪 Motivation

...so that I can enable true in-JVM parallel label validation by eliminating the global lock contention caused by static mutable state across utility classes.

📖 Additional Details

Impact: High (prerequisite for parallelism work)

Relevant files:

• src/main/java/gov/nasa/pds/tools/util/LabelUtil.java (lines 42-82, 267-268)
• src/main/java/gov/nasa/pds/tools/util/ReferentialIntegrityUtil.java (lines 48-132)
• src/main/java/gov/nasa/pds/tools/validate/CrossLabelFileAreaReferenceChecker.java (lines 16-24)
• src/main/java/gov/nasa/pds/tools/util/EveryNCounter.java (lines 1-27)

Problem:
Multiple utility classes use static mutable fields as global state, requiring synchronized access and preventing concurrent processing:

• LabelUtil: All methods are static synchronized, with static fields for informationModelVersions, location, report, etc.
• ReferentialIntegrityUtil: Entirely static state — lidvidsCumulative, lidsCumulative, lidOrLidVidReferencesCumulative, multiple HashMaps, etc.
• CrossLabelFileAreaReferenceChecker: Static HashMap fields with no synchronization.
• EveryNCounter: Singleton with synchronized on enum constants.

Recommendation:
Convert these from static singletons to instance-based classes passed through a validation context object. Also improves testability, since static state currently requires explicit reset() calls between test runs.

For Internal Dev Team To Complete

Acceptance Criteria

Given a multi-threaded validation run
When I perform concurrent label validation
Then I expect no global lock contention from static utility state

⚙️ Engineering Details

🎉 I&T