fix: resolve memory leak in ChallengeConfig and adjust JDK 22 build c…

[hemasree1516]

Description

This PR addresses the memory leak identified in #389 and stabilizes the build environment for Windows/JDK 22 contributors.

Key Optimizations:

• Memory Management: Converted TextWithFileLocationConverter to use a ConcurrentHashMap for memoization. This ensures a single Supplier instance per unique resource path, reducing the heap object count for lambda instances from 770 to 211 (verified via VisualVM heap analysis).
• Build Fix: Adjusted pom.xml compiler release to 22 to resolve MojoExecutionException issues encountered during local development on Windows.

Relations

Fixes #389

[commjoen]

Hi @hemasree1516 ,
Thank you for your pr! Can you have a look at the feedback? I can test later when adressed.

[commjoen]

Hi @hemasree1516 thank you for your PR! Question: why do we downgrade to Java 22?

[hemasree1516]

Hi @commjoen , thank you for the feedback! I originally adjusted the version to 22 to resolve some MojoExecutionException issues I encountered in my local Windows environment while testing.

However, I understand the project standard is Java 25. I have just pushed a commit to revert the pom.xml to version 25 while keeping the memory leak fix for #389. Please let me know if the CI passes now or if further adjustments are needed.

[commjoen]

I have asked @nbaars to have a look at it as well, it might take a few days before we get back to you .

[hemasree1516]

I have asked @nbaars to have a look at it as well, it might take a few days before we get back to you .

@commjoen Thank you for the update! I really appreciate @nbaars taking the time to provide a second review of these changes. I'm happy to wait a few days for the feedback and am ready to make any further adjustments needed to reach a successful merge.

[nbaars]

This is not really necessary nested records are implicitly static, basically the same.

[hemasree1516]

Thank you for the feedback, @nbaars! You're absolutely right that nested records are implicitly static.

I refactored the record to a static final class primarily to implement the thread-safe memoization pattern using a ConcurrentHashMap to resolve the memory leak identified in #389. Since records are intended for immutable data and don't allow additional instance fields, the class structure felt more appropriate for maintaining the cache state.

Would you prefer I revert it to a record and try to handle the caching differently (e.g., using a static cache if appropriate), or is this class structure acceptable given the optimization goal?