fix: make DataFormatter cache configuration-aware

[skytin1004]

Purpose of the pull request

Closed: #1065

NumberDataFormatterUtils currently reuses the first DataFormatter created on a thread even when a later operation requests a different locale, date windowing mode, or scientific-format setting. This makes formatting order-dependent and can produce output in the wrong locale.

What's changed?

• Cache the DataFormatter together with its effective constructor configuration.
• Reuse the cached formatter only when use1904windowing, locale, and useScientificFormat all match; otherwise replace it.
• Add regression tests for sequential locale, 1904-windowing, and scientific-format changes while retaining coverage for cache reuse and explicit removal.
• Protect the test that changes the JVM default locale with JUnit's locale resource lock so it remains isolated under parallel test execution.

Verification:

• fesod-sheet test suite with the JVM default locale set to Korean: 897 tests passed.
• Locale-sensitive utility suites with the parallel-tests profile: 100 tests passed.
• GitHub Actions passed on JDK 8, 11, 17, 21, and 25, together with Spotless, license, and CodeQL checks.

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

[Copilot]

🟢 Approval recommended

The implementation addresses the reported stale-cache behavior with focused regression coverage and no unresolved issues.

Pull request overview

Makes the thread-local DataFormatter cache configuration-aware, preventing stale formatting settings across sequential operations.

Changes:

• Recreates cached formatters when locale, date windowing, or scientific formatting changes.
• Adds regression tests for configuration changes, cache reuse, and locale isolation.

File summaries

File	Description
NumberDataFormatterUtils.java	Stores and compares the formatter’s effective configuration.
NumberDataFormatterUtilsTest.java	Tests cache replacement and locale-safe parallel execution.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[alaahong]

LGTM

[pjfanning]

@delei I would recommend setting this on your DataFormatter.

https://www.javadocs.dev/org.apache.poi/poi/5.5.1/org/apache/poi/ss/usermodel/DataFormatter.html#setUseCachedValuesForFormulaCells-boolean-

[skytin1004]

Thanks, @pjfanning. Fesod uses its own formatter and already reads cached formula results. While checking this, I found that XLS formula errors are always returned as #VALUE!, regardless of the cached error. I'll follow up with a separate fix.